<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 18, 2014, at 7:03 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""><br class="">
On 19 Dec 2014 03:50, "Marcos Klein" <<a href="mailto:mklein0@gmail.com" class="">mklein0@gmail.com</a>> wrote:<br class="">
><br class="">
> I have two update requests for PEP 440.<br class="">
><br class="">
> Could PEP 440 date-based version identifier examples be extend to include full timestamp version identifiers?</p><p dir="ltr" class="">Sure, that's not a change to the semantics, just some additional examples.</p><p dir="ltr" class="">> This leads me to my second request.<br class="">
><br class="">
> Could the effects of normalized version identifiers be clarified when it comes to package builds? <br class="">
><br class="">
> 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:<br class="">
><br class="">
> dated_release-20141218.18-p27-none-any.whl<br class="">
><br class="">
> Previous releases of setuptools would build:<br class="">
><br class="">
> dated_release-20141218.000018-p27-any.whl<br class="">
><br class="">
> 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.</p><p dir="ltr" class="">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.</p><p dir="ltr" class="">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.</p><p dir="ltr" class="">Cheers,<br class="">
Nick.<br class=""></p></div></blockquote><br class=""></div><div>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.</div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>