2009/6/11 P.J. Eby
Dev tags are so that while you're doing development, your locally-installed versions can be distinguished from one another.
Distinguished by what? What code (that you didn't write yourself, purely for internal use) needs to parse your dev tag?
Distinguished by setuptools for processing version requirements of scripts, or require() statements in code, and installation requirements of newly-installed code.
So will setuptools be modified to use the new code? If not, the PEP is directly competing with setuptools. And the new PEP will probably not be adopted by anyone currently using setuptools (after all, switching is all cost and no benefit). If setuptools *will* be changing, then setuptools users have to choose whether to conform to the new version of setuptools (and hence the spec) or to remain on an old/forked version of setuptools. That's a genuine choice - although maybe not one that people will like being given. My understanding was that setuptools was a success at least in part due to its policy of catering for as many variations on existing policy as possible, effectively refusing to enforce policy, but rather to adapt to existing use. If the new PEP isn't designed precisely to limit variation, and enforce policy even if that does mean excluding certain current usages, then I don't see why the PEP doesn't just say "adopt setuptools version code" [1]. So I guess I'm missing the point of the PEP, given the existence of setuptools.
For example, if I'm working on two projects that are distributed via SVN and one depends on the other, if I update one, it may require an update of the other; the failure of the .dev#### version requirement in the first one will inform me of the need to "svn up" the second project and rerun "setup.py develop" on it.
This is a routine circumstance in at least my development cycle; I would expect that it's the case in other open source development workflows as well as proprietary ones.
But setup.py develop is a setuptools extension. The PEP doesn't say anything about setuptools. Are you saying that setuptools *will* be modified to use the PEP version rules? And hence, what are you saying about the relationship between the principle I stated above (assuming I didn't misinterpret things) and the (implicit) goals of the PEP process? Paul. [1] Actually, if I was being cynical, I could say that the reason is to avoid alienating people who don't like / use setuptools. Either way, it may be that the reason I'm making such a fuss is that I'm (unconsciously) reacting against the same aspects of the PEP that I dislike in setuptools.