Amend PEP 440 regarding timestamp based version identifiers and packaging
I have two update requests for PEP 440. Could PEP 440 date-based version identifier examples be extend to include full timestamp version identifiers? The version identifiers I use in a continuous integration build are derived from ISO8601 time stamps. YearMonthDay "." HourMinuteSecond (UTC) ex. date -u +'%Y%m%d.%H%M%S' This version identifier format has the peculiar aspect of having a number of leading 0s in the version segment when a package is created at the beginning of a new day. 20141218.000018 I just want to make sure any test cases include this version identifier format. This leads me to my second request. Could the effects of normalized version identifiers be clarified when it comes to package builds? The normalization section in PEP 440 only seems to discuss the use of normalization in parsing and processing of the version identifier. I was quite surprised when my package build for the above version identifier became the following under setuptools 8: dated_release-20141218.18-p27-none-any.whl Previous releases of setuptools would build: dated_release-20141218.000018-p27-any.whl This is jarring as it is an unexpected interpretation of PEP 440. It is the classic pointer argument. I want to call it THIS, but it really is THAT. -- Marcos Klein
On 19 Dec 2014 03:50, "Marcos Klein" <mklein0@gmail.com> wrote:
I have two update requests for PEP 440.
Could PEP 440 date-based version identifier examples be extend to include
This leads me to my second request.
Could the effects of normalized version identifiers be clarified when it comes to package builds?
The normalization section in PEP 440 only seems to discuss the use of normalization in parsing and processing of the version identifier. I was quite surprised when my package build for the above version identifier became the following under setuptools 8:
dated_release-20141218.18-p27-none-any.whl
Previous releases of setuptools would build:
dated_release-20141218.000018-p27-any.whl
This is jarring as it is an unexpected interpretation of PEP 440. It is
full timestamp version identifiers? Sure, that's not a change to the semantics, just some additional examples. the classic pointer argument. I want to call it THIS, but it really is THAT. This is primarily an RFE for setuptools 8+ requesting the ability to skip the normalisation step. At the PEP level, it's already covered by the fact that installers are required to be able to do dynamic normalisation. That said, it's likely worth adding a clarifying paragraph that our perspective is that while installation tools MUST normalise versions, build tools SHOULD normalise versions. Cheers, Nick.
-- Marcos Klein
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Dec 18, 2014, at 7:03 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 Dec 2014 03:50, "Marcos Klein" <mklein0@gmail.com <mailto:mklein0@gmail.com>> wrote:
I have two update requests for PEP 440.
Could PEP 440 date-based version identifier examples be extend to include full timestamp version identifiers?
Sure, that's not a change to the semantics, just some additional examples.
This leads me to my second request.
Could the effects of normalized version identifiers be clarified when it comes to package builds?
The normalization section in PEP 440 only seems to discuss the use of normalization in parsing and processing of the version identifier. I was quite surprised when my package build for the above version identifier became the following under setuptools 8:
dated_release-20141218.18-p27-none-any.whl
Previous releases of setuptools would build:
dated_release-20141218.000018-p27-any.whl
This is jarring as it is an unexpected interpretation of PEP 440. It is the classic pointer argument. I want to call it THIS, but it really is THAT.
This is primarily an RFE for setuptools 8+ requesting the ability to skip the normalisation step. At the PEP level, it's already covered by the fact that installers are required to be able to do dynamic normalisation.
That said, it's likely worth adding a clarifying paragraph that our perspective is that while installation tools MUST normalise versions, build tools SHOULD normalise versions.
Cheers, Nick.
Originally I directed this here, though I think now it’s because I forgot how numbers work. I was thinking that currently the normalization would result in _wrong_ versions not just ugly versions. I forgot that 0018000 won’t normalize to the same thing as 0000000 so it’s likely safe to do that I think. Originally I was thinking that without doing the int() you’d get different results, something which in hindsight is obviously wrong. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
participants (3)
-
Donald Stufft -
Marcos Klein -
Nick Coghlan