<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On October 14, 2015 at 1:37:05 PM, Nathaniel Smith (<a href="mailto:njs@pobox.com">njs@pobox.com</a>) wrote:</div> <div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; 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;"><span><div><div></div><div><p dir="ltr">On Oct 14, 2015 10:04 AM, "Ionel Cristian Mărieș" <<a href="mailto:contact@ionelmc.ro">contact@ionelmc.ro</a>> wrote:<br>><br>><br>> On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>>><br>>> some packages were unable to work with the postN suffix.<br>><br>><br>> Can you elaborate a bit more here?<br>></p><p dir="ltr">Apparently some packages were making assumptions about the format of the numpy.__version__ string, and having .postN in there caused errors when they tried to process it. (It would be helpful if there were a little permissively licensed standalone implementation of PEP 440 comparisons, suitable for the "if pkg.version > ...:" checks that people insist on doing -- I couldn't find one in some quick searches.)</p></div></div></span></blockquote></div><p><a href="https://github.com/pypa/packaging">https://github.com/pypa/packaging</a></p><p>It’s what both pip and setuptools use (though we embed it, but it’s fine to depend on it too).</p><div><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; 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;"><span><div><div><p dir="ltr"><br class="Apple-interchange-newline">IIUC, the specific problems numpy ran into that caused the creation of .postN releases were:<br>- oops, didn't sign the uploads, re-upload identical file with proper signature attached -> not allowed. (I'm not sure if these were embedded or detached signatures. Either way it'd be nice if pypi allowed it, but for embedded signatures in particular I can see how this might be a hassle.)</p></div></div></span></blockquote></div><p>I don’t think we allow embedded signatures, it would be reasonable to allow uploading detached signatures after the fact though.</p><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; 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;"><span><div><div><p dir="ltr"><br>- our OS X maintainer tried to use twine to upload OS X wheels for the existing release; instead it created a new release. Not sure if a bug was filed on twine, but if not then one probably should be. As a workaround our release docs now say "always upload wheels by hand using the web interface, never use setup.py upload or twine".</p></div></div></span></blockquote></div></div><p>This shouldn’t create a new release unless you’ve changed the version number (including adding post releases). If you can reproduce on Test PyPI I can fix it.</p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; 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;"><span><div><div><p dir="ltr"><br class="Apple-interchange-newline">My feeling is that pypi is correct to disallow the mutation of releases once they become public, but that the ergonomics around this could probably be improved :-). A more general solution that might be nice to have Someday would be if you could upload a release in one step, and then get a private link to poke at what was uploaded and make sure it looks correct, before making it public in a second step.</p></div></div></span></blockquote></div><p>The ergonomics of it is pretty bad. Once we kill PyPI legacy and Warehouse is the thing we’re using, improving things like that will be a lot simpler.</p><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; 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;"><span><div><div><p dir="ltr"><br class="Apple-interchange-newline">CC'ing the release manager and OS X maintainer in question, in case I got something wrong or more details are wanted...</p><p dir="ltr">-n</p>_______________________________________________<span class="Apple-converted-space"> </span><br>Distutils-SIG maillist - Distutils-SIG@python.org<span class="Apple-converted-space"> </span><br>https://mail.python.org/mailman/listinfo/distutils-sig<span class="Apple-converted-space"> </span><br></div></div></span></blockquote><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div> <div id="bloop_sign_1444846111623877120" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><div>-----------------</div><div>Donald Stufft</div><div>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div></body></html>