[Distutils] version scheme: a case for dropping ".devNNN" and ".postNNN"

[Paul Moore]

2009/6/11 P.J. Eby <pje at telecommunity.com>:
>> > 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.