-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setuptools 8 strips leading zeros in packaging for date based releases #302
Comments
Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft): This is expected behavior with PEP 440. It interprets each segment in the 20140510.003458 as an integer which means that it essentially does I have to admit I'm not sure what the 003458 signifies, is that HHMMSS with a 24 hour clock? I'll admit that when we wrote PEP 440 I don't think anyone considered what would happen if someone wanted to expand date based version numbers to also include 24 hour clocks. The reason for the stripping of the leading 0 is so that something like |
Original comment by mklein0 (Bitbucket: mklein0, GitHub: mklein0): The timeformat is: Ok, my interpretation of the example was leading |
Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft): It's acceptable in that the version parsing will accept it, but it'll normalize it so that there is no leading zeros. I think this issue can be closed here since this is accurate with what PEP 440 says. If you think that PEP 440 should be adjusted please bring that up on distutils-sig as we're treating PEP 440 as provisional until we make sure all the issues get shaken out. |
Original comment by mklein0 (Bitbucket: mklein0, GitHub: mklein0): We can close this issue. I will bring up my example and ask for a clarification that the normalized version identifier will be used in package creation on distutils-sig. The use of the normalized version identifier in the packaging is another point of confusion. PEP 440 only referred to normalization in the context of parsing and processing, not in package creation. |
Traditionally Python Unidecode followed the versioning scheme used by the original Perl module. This doesn't make sense any more because: 1) Perl Text::Unidecode itself switched to a different versioning scheme long ago http://search.cpan.org/~sburke/Text-Unidecode-1.30/ 2) Python Unidecode has now sufficiently diverged from Perl version so that matched version numbers are no longer useful, 3) setuptools (>= 8) began mangling version numbers, yielding confusion because Unidecode 0.04.x now sometimes appears as 0.4.x pypa/setuptools#302
I know this issue is pretty old but I am totally confused about what PEP440 says and about how date based versions in reality work. PEP 440 says
When using for example
I am using setuptools 41.0.1 |
…l raise warnings in build tools such as pypa/setuptools#302
… that will raise warnings in build tools such as pypa/setuptools#302 (#1195)
Originally reported by: mklein0 (Bitbucket: mklein0, GitHub: mklein0)
I am currently date based release version numbers to manage releases. After upgrading to setuptools 8, release segments with leading zeros in them are being striped.
The following setup.py example would generate a package name of:
After setuptools 8:
Along with the following warning:
I believe PEP440 allows for date based version identifiers, so this is unexpected.
Code to generate packages:
The text was updated successfully, but these errors were encountered: