<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 Aug 23, 2016, at 5:05 PM, Daniel Holth <<a href="mailto:dholth@gmail.com" class="">dholth@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I would be sad to see .zip go. I would rather the rule be '0 or 1 sdists'. For my own selfish reasons I am trying to generate sdists with SCons, and it happens to expect the tar command but can already generate zips cross platform, so I will need to patch SCons' archiver to comply with the PEP. Sure, it only affects 2 packages, but they are mine.<br class=""></div></div></blockquote><div><br class=""></div><div>It will be 0 or 1 sdists, having two sdists for a single version is not going to be a thing. However, standardizing around a single extension makes implementing that easier. It also makes it easier for people consuming things from PyPI because there is less variation in what they’re going to get. As time goes on, if we standardize on a single format, all of the older formats will end up just being old cruft that’s laying around, that nobody really installs or uses so it doesn’t really matter if the tooling handles them or not.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">ZIP is interesting from the required C extensions angle because you can compress individual members with LZMA for example, breaking the 'only requires zlib' constraint; zipimport would not like those either. If the package already required Python 3.6 would this be a problem? Or the sdist could require the go compiler, and not work, but at least the packaging tool would not be the failure point.</div></div></div></blockquote><div><br class=""></div><div>I already plan to disallow uploads of wheels and sdists (if we keep .zip sdists) that use any storage methods besides ZIP_STORED and ZIP_DEFLATED. At least .tar.xz tells you on the tin if your current Python can support extracting it, compressing something in a zip file with LZMA is just a russian roulette of “will this extract or will it not?”. As far as whether or not depending on Python 3.6 means it’s no really an issue, that doesn’t solve the problem because the lzma module is an *optional* module, so any particular instance of Python 3.6 may or may not have it available.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Wheel comes with a converter for bdist_wininst. They are conceptually very similar, both zip format, but bdist_wininst prepends an .exe installer.</div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 23, 2016 at 4:13 PM Ian Cordasco <<a href="mailto:graffatcolmingov@gmail.com" target="_blank" class="">graffatcolmingov@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Aug 23, 2016 at 2:03 PM, M.-A. Lemburg <<a href="mailto:mal@egenix.com" target="_blank" class="">mal@egenix.com</a>> wrote:<br class="">
> On 23.08.2016 18:46, Donald Stufft wrote:<br class="">
>> Since it seemed like there was enough here for a proper PEP I went ahead and<br class="">
>> write one up, which is now PEP 527. The tl;dr of it is that:<br class="">
>><br class="">
>> * Everything but sdist, bdist_wheel, and bdist_egg get deprecated.<br class="">
><br class="">
> -1 on removing bdist_wininst and bdist_msi. If PyPI is supposed<br class="">
> to retain the status of the main website to go search for Python<br class="">
> package downloads, it needs to be able to provide ways of hosting<br class="">
> all distribution types which are supported by distutils, including<br class="">
> ones which target platform configuration management system such as<br class="">
> the Windows one.<br class="">
><br class="">
> The number of downloads is really irrelevant for this kind of<br class="">
> argument. Since the PEP proposes to keep the existing uploads<br class="">
> around, I also don't follow the argument of reduced maintenance.<br class="">
> PyPI will still have to host and support downloading those file<br class="">
> types.<br class="">
><br class="">
> To me, all this sounds a lot like eventually turning PyPI into a<br class="">
> pip package index, which no longer serves the original intent of<br class="">
> a Python package index. I think that's taking a wrong turn in the<br class="">
> development of such an index.<br class="">
><br class="">
> IMO, we should aim to reunite separate indexes such as the<br class="">
> one used for conda or the win32 index maintained by<br class="">
> Christoph Golke back into PyPI, not create even more<br class="">
> separation by removing platform specific formats.<br class="">
<br class="">
I disagree. As it is, tools like Twine only introspect the more common<br class="">
file formats to upload them to PyPI and has not had a single user<br class="">
complain about it. Given that Twine is advertised as the preferred<br class="">
method to upload to PyPI, you might expect that this would have been<br class="">
requested already. Alas it has not. No one using modern tooling for<br class="">
package management is uploading these file types.<br class="">
<br class="">
Even if the statistic of downloads (which actually is valid) doesn't<br class="">
sway you, maybe this will. Alternatively, maybe you will help maintain<br class="">
support for these file types in Warehouse?<br class="">
_______________________________________________<br class="">
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank" class="">Distutils-SIG@python.org</a><br class="">
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank" class="">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class="">
</blockquote></div></div></div>
_______________________________________________<br class="">Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" class="">Distutils-SIG@python.org</a><br class=""><a href="https://mail.python.org/mailman/listinfo/distutils-sig" class="">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class=""></div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">—<br class="">Donald Stufft<br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>