After reading +Tarek Ziadé's blog post on promoting the Django community to not use setuptools, I decided to try to refresh myself on the various PEPs regarding packaging to see where things are.

So PEP 386 (http://python.org/dev/peps/pep-0386/) is about version numbers and is accepted. If your version numbers don't meet the regex, fix them.

PEP 390 (http://python.org/dev/peps/pep-0390/) standardizes the format of setup.cfg so that all the metadata you specified in your setup.py file can be statically specified instead. Nice that you don't need to execute code to get at the metadata. This is a distutils2/packaging thing (and just to refresh people, 'packaging' is what distutils2 will be named when it ends up in the stdlib in hopefully Python 3.4).

PEP 241, 314, and 345 (http://www.python.org/dev/peps/pep-0345/ ; PEP 426 is potentially the next draft) all specify metadata that ends up in your METADATA field (more on that in a minute). Now your METADATA file is to be generated by 'packaging', which means it is generated by reading your setup.cfg, but I don't know if there is a 1:1 correlation between names in the two files.

PEP 425 (http://python.org/dev/peps/pep-0425/) is trying to specify a way to name project files such that different files for different versions/OSs can exist in the same directory.

PEP 376 (http://python.org/dev/peps/pep-0376/) specifies how to store the metadata of an installed project (the METADATA file I mentioned previously plus other stuff) so that it is standardized, can be used for uninstalling, etc.

So the only thing I'm not totally clear on is the setup.cfg -> METADATA relationship in terms of field names. After that I just don't know where 'packaging' is ATM since the last commit was 3 months ago (http://hg.python.org/distutils2/) and it still says that 'packaging' made it into Python 3.3. But it does seem everything is there to get packaging in Python straightened out, it just needs some volunteer time to get the code written.
Shared publiclyView activity