[Distutils] version scheme: a case for dropping ".devNNN" and ".postNNN"
ianb at colorstudy.com
Thu Jun 11 18:03:19 CEST 2009
On Thu, Jun 11, 2009 at 10:53 AM, P.J. Eby<pje at telecommunity.com> wrote:
> At 03:16 PM 6/11/2009 +0100, Paul Moore wrote:
>> 2009/6/11 P.J. Eby <pje at telecommunity.com>:
>> > PyPI uploads aren't a suitable basis for analyzing "dev" use cases,
>> > since
>> > the whole point of having a "dev" tag is for *non-released* versions.
>> > (E.g., in-progress development via SVN.)
>> If it's non-released, I've yet to see a clear explanation of why the
>> PEP is relevant. Who is going to use an API from the PEP to parse your
>> "version number", and why?
>> > 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.
> 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.
Agreed, I do this all the time. Pylons dev versions also regularly
rely on other packages with a dev version, and people regularly use
these non-released versions, with dependencies detected and installed
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
More information about the Distutils-SIG