neogeographica / expak Goto Github PK

This should do it:

import errno
try:
    os.makedirs(out_dir)
except OSError, e:
    if e.errno != errno.EEXIST:
        raise

Travis CI says it works, so who am I to argue?

Aside from actually trying it out locally (and updating tox.ini to include it), it looks like PyPy support is really just a matter of updating the readme and the trove classifiers.

It's not worth spinning a new release for this change, but I should pick it up if/when some other thing motivates a new release.

(And presumably expak should also work fine with Jython and IronPython? But no native Travis CI support, and harder to test locally.)

When/if I rev this module again I should use https://pypi.python.org/pypi/twine

3.4 should have a final release soon-ish.

Hopefully the only necessary changes will be to update the readme, tox & Travis CI config, & the trove classifiers. The readme should just say "3.x" support... nothing in expak will get broken by a Python minor release. (Or maybe "3.2 and later"?)

If pip is installed by default with 3.4 installers, that could be mentioned in the readme too.

It's not a big thing but I should distinguish between those error cases in the result of the first read.

If the read returns fewer than len(PAK_FILE_SIGNATURE) bytes, then the code should raise IOError to be consistent with the behavior of the other "short read" cases.

Should be doable I think? But currently on OS X:

If in a virtualenv, the process fails because site-packages/setuptools/cli-64.exe is missing.

If not in a virtualenv, the process fails after creating simple_expak-script.py with "error: setuptools/cli-64.exe: Error". For the setuptools outside of virtualenv, it doesn't look like cli-64.exe is in the egg.

If that's the case, would be nice to drop one piece out of the release process.

Might as well continue using this as a concrete way to explore various things. Take a look at https://travis-ci.org/ as per http://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/

Sure why not.

cf. http://www.pip-installer.org/en/latest/reference/pip_install.html#vcs-support

Mention in readme.

1d0f23f and 3698585 make the long_description construction in setup.py rely on files that are not (currently) in the sdist.

• fix that, one way or another
• make sure to test install from sdist before uploading & tagging v1.0
• http://pablissimo.com/381/get-travis-ci-to-do-your-python-packaging-tests-for-you

I need to target a couple of the IOError-from-incomplete-read cases to max out the coverage report.

Also it would be good to have tests for a pak with a corrupted filetable, and a converter that intermittently throws exceptions and/or returns false. Those are a bit harder to define the success cases for.

Actually one easy-ish test to add would be for a converter that always returns False.

Might be able to use some automatic setuptools 2to3 magic.

pytest should eventually reap them and they might be handy for failed tests.

I even have a comment that says "leave the output files in place", but then I don't. Part of some testing-of-tests that didn't get completely cleaned up... not urgent to fix, but might as well next time I'm in the neighborhood.