[prev in list] [next in list] [prev in thread] [next in thread]
List: python-distutils-sig
Subject: Re: [Distutils] Amend PEP 440 regarding timestamp based version identifiers and packaging
From: Donald Stufft <donald () stufft ! io>
Date: 2014-12-19 0:09:42
Message-ID: 33643629-E985-4798-B9AB-0003D20F66FC () stufft ! io
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> 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
[Attachment #5 (unknown)]
<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>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic