Add option to package build to disable normalization of version identifier

Originally reported by: mklein0 (Bitbucket: mklein0, GitHub: mklein0)

---

Could an option be added to package builds to disable the use of normalized version identifiers in the final package file name?

Under previous versions of setup tools a version identifier of 20140510.003458 would generate a package name of:

dated_release-20140510.003458-cp27-none-macosx_10_9_intel.whl

After setuptools 8:

dated_release-20140510.3458-cp27-none-macosx_10_9_intel.whl

My primary concern is for older installation tool/devpy versions, the package version matching will fail if I start using the new normalized package names. And I do not want to have to test it.

Aesthetics is another aspect as in this case, the version identifier is actually an encoding of an ISO8601 timestamp.:

date -u +'%Y%m%d.%H%M%S'

This request is derived from issue #302

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/308

[kdubezerra]

I also noticed that, if I set the version number as, say, 1.2.3-rc1, setuptools normalizes it to 1.2.3rc1. This created several problems for me when generating debian packages. Allowing such kinds of normalization do be disabled would be a major improvement.

[jobevers]

Would also like to be able to disable normalization, 1.2.3-rc1 being normalized to 1.2.3rc1 is causing problems for packaging for me as well.

[jaraco]

@dstufft, do you have any opinion on this? IIRC, it was your contribution that added the normalization. What would be the ramifications of allowing bypassing of this normalization?

[dstufft]

@jaraco I think as long as you still validate that it is a PEP 440 version (or warn if not.. I don't think we have it set to hard fail), not doing the normalization shouldn't be a big deal. I think my only reason to normalize was just to get everyone using the normal forms as the default since that makes things a bit saner I think. However allowing a flag to bypass normalization should not have any negative affect.

[jaraco]

Thanks @dstufft. Glad to hear this wouldn't be a blocker. @mklein0 or others, would you consider putting together a pull request?

[nomadlogic]

Hi there, I was wondering if there was a status update or further discussion on this issue. I've just run into this when our CI pipeline built a new package (which appends a short git has to the version string) was changed to a different hash.

Version is: 2.4.5.5513c055
/usr/local/lib/python2.7/site-packages/setuptools/dist.py:332: UserWarning: Normalizing '2.4.5.5513c055' to '2.4.5.5513rc55'

It would seem to my quick analysis that there is an overly greedy regex munging version strings...

[backbohne]

Not nice, but a workaround that works for me:

add this to your setup.py

import pkg_resources
pkg_resources.extern.packaging.version.Version = pkg_resources.SetuptoolsLegacyVersion

[richard-reece]

Just ran into this myself. I've already disabled the PEP 440 warnings and now I have to work around this also :(

We're packaging pre-releases following the semver.org standard, entirely for internal use only. I can maybe understand PyPI rejecting "internal only" versions at registration/upload time, but rejecting it outside of a public arena seems a little heavy-handed.

My solution was to modify our version strings from "2.2.0-a046027" to "2.2.0-pre.a046027" - I couldn't figure a reasonable way to disable the normalization code through monkey-patching.

I am using this monkeypatch to disable the normalization:

from setuptools.extern.packaging import version
version.Version = version.LegacyVersion

[dstufft]

I threw together a quick proof of concept for adding a normalize_version=False parameter to setup() that would allow a project to disable version normalization. It does not prevent the warning about non PEP 440 versions (because it is true that using those versions are likely to cause issues), but it does provide a path for people who need a very specific version string.

That branch can be found at https://github.com/pypa/setuptools/compare/dont-normalize, it's only two lines of code plus re-indenting a block of code to be guarded by an if statement. I don't have time right now to develop it further, it would presumably require some tests and someone to shepherd it through the contribution process, but if someone does have the time, that code there is working.

[richard-reece]

Thanks, Donald!