2009/6/11 Eric Smith :

Paul Moore wrote:

...

2009/6/11 P.J. Eby :

...

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?

I would, if my test environment used buildout to grab the latest versions of my own packages from my own servers. And that's in fact how I operate internally.

...

Distinguished by what? What code (that you didn't write yourself, purely for internal use) needs to parse your dev tag?

Because it's my own code this use case doesn't need to be supported?

That's not what I meant, but I suspect that if I try to clarify, I'll make things worse, as I'm losing track of things at this point :-( Does Ben's proposed solution satisfy your needs? If not, let's try to understand why, and we can start the discussion again with a clean slate.

At 08:22 AM 6/12/2009 +1000, Ben Finney wrote:

"P.J. Eby" writes: > Dev tags are so that while you're doing development, your > locally-installed versions can be distinguished from one another. How is “distinguished from one another” different from “compare sequentially previous or subsequent to one another”?

First, more than one version can co-exist in .egg form, and there may be a need to depend on an exact version. Second, as already shown in other examples, there is a need for the installed development version to be compared against a desired development version, and these requirements are expressed by version comparison strings.

What is wrong with using the version comparison semantics without special-cased words for this purpose?

Please explain how you intend to designate "development" versions that compare less than the equivalent non-development versions in your scheme.