> On Dec 18, 2014, at 7:03 PM, Nick Coghlan <[email protected]> wrote: > > > On 19 Dec 2014 03:50, "Marcos Klein" <[email protected] > <mailto:[email protected]>> 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
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
