[Distutils] Amend PEP 440 regarding timestamp based version identifiers and packaging

[Donald Stufft]

> On Dec 18, 2014, at 7:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> 
> On 19 Dec 2014 03:50, "Marcos Klein" <mklein0 at gmail.com <mailto:mklein0 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141218/458c26d2/attachment-0001.html>