[Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version

[Nick Coghlan]

On 17 August 2014 02:11, Donald Stufft <donald at stufft.io> wrote:
>
> On Aug 16, 2014, at 11:37 AM, Jason R. Coombs <jaraco at jaraco.com> wrote:
>
> Thanks Donald for the extensive work on this. It all looks generally good.
>
> One thing that stuck out as slightly surprising – the use of ‘_’ as a
> separator. I imagine most people consider the underscore to be yet another
> alpha character, similar to [a-zA-Z]. If it is to be a separator, I suggest
> that the PEP give some examples. As is, I didn’t see any examples that
> showed ‘_’ as a separator.
>
>
> It’s not a preferred separator, it’s use is mostly because of various
> normalization schemes, particularly Wheel, which will convert a ``-`` to a
> `` _`` in the version. Right now pip considers them equal because it was
> causing some breakage with Wheels. This rationale should probably be given
> in the PEP though.
>
> The original bug report in pip for this was
> https://github.com/pypa/pip/issues/1150.
>
>
> Related, I would suggest a consistent scheme for local version tags. Why not
> have local version tags have the same syntax as primary version numbers?
> That is, allow the same character set, pre and post versions, etc, just
> separated by a +. At the very least, I would expect local versions to allow
> underscores.
>
>
> Originally local versions were just integers separated by dots. We wound up
> where we are so that downstream distributions can put more information
> inside of it. For instance Instead of Ubuntu taking a version like 1.0, and
> making it 1.0+1, they can do 1.0+ubuntu.1 or similar so that it’s obvious
> from the version number that this version is different than say Fedora, who
> might have also patched it and have 1.0+fedora.1.

Right. In the Fedora (et al) case, the local version ordering scheme
also matches the way yum orders the RPM release field, so it becomes
possible to map the release field (which tracks patches and spec file
changes) directly to the Python level "local version".

One big advantage of the more relaxed rules around the local version
identifier component is that DVCS hashes are allowed, you just want to
include a serial number (e.g. number of commits since the last rebase)
first to ensure sensible ordering.

> I’m not sure what the use case is for pre/post/etc versions in the local
> version. At the point you’re doing more than simple patching you’re probably
> making a full fledged fork which should have it’s own name and version
> numbers I think?

Agreed. For use of the local version field to be appropriate, we
should be looking at full API compatibility with the public version
identifier.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia