On Sun, May 27, 2012 at 12:58 PM, PJ Eby firstname.lastname@example.org wrote:
Is setup.cfg already in dist-info? I guess if it isn't, you could just add it, using the same mechanism above. Hm.... (goes to look at packaging docs)... Ouch. I'm seeing a bigger problem, which is that without either the ability to do "setup_requires" or to ship an sdist with a hook-altered setup.cfg, it doesn't look like you can actually implement all of setuptools' build functionality with just packaging. (e.g. Setuptools can ship an sdist whose contents and version were determined using revision control info, but which does not then require the revision control tool when installing from the sdist, as the sdist contains a pre-built manifest, and a pre-built setup.cfg with hardcoded version numbers copied from the original revision control info.)
I've already got sort of a version of that for some of the packages I maintain here: https://svn.stsci.edu/trac/ssb/stsci_python/browser/stsci.distutils/trunk/st...
It's a basic setup_hook that tacks the SVN revision on to version string in the metadata (and only if the version contains ".dev"). The SVN info itself comes from a generated module called 'version.py' that ships with the sdist and contains hard-coded version info and SVN revisions. The main reason it's a Python module is that it also contains an __version__ that can be imported by the main module of the package.
This particular solution works for me. But the point is that it can be done pretty easily. However, the lack of a setup_requires-like feature still makes things pretty impossible short of shipping a copy of all the required setup hooks with the projects that use them. Certainly doable, but far from ideal.
I really hope I'm not going to have to write setuptools2 to work around these limitations. ;-) (Preferably, if I do write a setuptools2, I hope it can all be done using proper setup hooks on top of packaging/distutils2, without monkeypatching anything.)
Please, please no monkeypatching :)