Skip to content
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

Closed
ghost opened this issue Dec 17, 2014 · 7 comments
Closed

Comments

@ghost
Copy link

ghost commented Dec 17, 2014

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:

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

Along with the following warning:

/VirtualEnv/stools/lib/python2.7/site-packages/setuptools/dist.py:289: UserWarning: The version specified requires normalization, consider using '20140510.3458' instead of '20140510.003458'.
self.metadata.version,

I believe PEP440 allows for date based version identifiers, so this is unexpected.

Code to generate packages:

from setuptools import setup, find_packages

setup(
    name='dated_release',
    version='20140510.003458',
    description='Example of a dated release  %Y%m%d.%H%M%S',
    packages=find_packages(),
    )

@ghost
Copy link
Author

ghost commented Dec 17, 2014

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 ".".join([str(int(x)) for x in "20140510.003458".split(".")]).

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 00 is equal to 0 because that's generally how people think of those versions. I'm not sure I can think of a good way to change PEP 440 that would allow the exact version string you've picked without breaking the 00 == 0 rule. Probably the best way for you to get the effect you're trying is to either remove the . or add more . and do something like 20140510.0.34.58 or even 2014.05.10.0.34.58 or 20140510003458.

@ghost
Copy link
Author

ghost commented Dec 17, 2014

Original comment by mklein0 (Bitbucket: mklein0, GitHub: mklein0):


The timeformat is: %Y%m%d.%H%M%S or YearMonthDate.HourMinuteSeconds

Ok, my interpretation of the example was leading 0 is acceptable in the version identifier (due to the date based example), but be aware that it is interpreted as 00 == 0

@ghost
Copy link
Author

ghost commented Dec 17, 2014

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.

@ghost
Copy link
Author

ghost commented Dec 18, 2014

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.

@ghost ghost added major bug labels Mar 29, 2016
@ghost ghost closed this as completed Mar 29, 2016
avian2 added a commit to avian2/unidecode that referenced this issue Jan 5, 2018
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
@martinm82
Copy link

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

Date based release segments are also permitted. An example of a date based release scheme using the year and month of the release:
And as examples shows this:

2012.04
2012.07
2012.10
2013.01
2013.06

When using for example 2019.07 as a version I receive a warning saying

setuptools/dist.py:472: UserWarning: Normalizing '2019.07' to '2019.7' normalized_version

I am using setuptools 41.0.1

@jaraco
Copy link
Member

jaraco commented Oct 4, 2019

PEP 440

@jaraco
Copy link
Member

jaraco commented Oct 4, 2019

@dstufft, @ncoghlan How do you feel about updating the date examples in PEP 440 to elide the leading zeros?

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants