On 6 May 2014 08:48, "Marcus Smith" <qwc...@gmail.com> wrote: >> >> >> In the custom RPM case, the PEP 440 "local version" and the leading numeric portion of the RPM "release" should *still* be the same (just as they should be for distro packages), but you'd choose a different local version/RPM release value based on how you wanted the ordering to be handled relative to other RPMs - it wouldn't be governed by any Python level policy. >> >> However, I'm wondering if the rules for local version identifiers should be relaxed to allow arbitrary alphanumeric subcomponents in the integrator suffix. The RPM release field allows things like "0.git.15.abcdefabc" - I'd really like to be able to publish that as the "local version" in the Python metadata. >> >> From Barry's description of the "2ubuntu3" style suffixes used when Ubuntu includes patches Debian doesn't, a more permissive integrator suffix would also help in the Debian/Ubuntu ecosystem. > > > yea, if you recall, at one point that idea was ".localN", then it switched to "-N" > the switch seemed to be in this post where Donald references a discussion with Noah. > https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-integrator-suffix-to-pep-440#comment-5773507 > > wondering if alphanumerics were intentionally excluded, or just not considered given the context at the time was about ".localN" vs "-N"
I don't recall making a conscious decision - I think I just copied the existing restrictions for "Version" without accounting for the fact the version constraints are all defined to ignore the local version information anyway. Cheers, Nick. > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
