> > > 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"
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig