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.
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. Wheel comes with a converter for bdist_wininst. They are conceptually very similar, both zip format, but bdist_wininst prepends an .exe installer. On Tue, Aug 23, 2016 at 4:13 PM Ian Cordasco <graffatcolmin...@gmail.com> wrote: > On Tue, Aug 23, 2016 at 2:03 PM, M.-A. Lemburg <m...@egenix.com> wrote: > > On 23.08.2016 18:46, Donald Stufft wrote: > >> Since it seemed like there was enough here for a proper PEP I went > ahead and > >> write one up, which is now PEP 527. The tl;dr of it is that: > >> > >> * Everything but sdist, bdist_wheel, and bdist_egg get deprecated. > > > > -1 on removing bdist_wininst and bdist_msi. If PyPI is supposed > > to retain the status of the main website to go search for Python > > package downloads, it needs to be able to provide ways of hosting > > all distribution types which are supported by distutils, including > > ones which target platform configuration management system such as > > the Windows one. > > > > The number of downloads is really irrelevant for this kind of > > argument. Since the PEP proposes to keep the existing uploads > > around, I also don't follow the argument of reduced maintenance. > > PyPI will still have to host and support downloading those file > > types. > > > > To me, all this sounds a lot like eventually turning PyPI into a > > pip package index, which no longer serves the original intent of > > a Python package index. I think that's taking a wrong turn in the > > development of such an index. > > > > IMO, we should aim to reunite separate indexes such as the > > one used for conda or the win32 index maintained by > > Christoph Golke back into PyPI, not create even more > > separation by removing platform specific formats. > > I disagree. As it is, tools like Twine only introspect the more common > file formats to upload them to PyPI and has not had a single user > complain about it. Given that Twine is advertised as the preferred > method to upload to PyPI, you might expect that this would have been > requested already. Alas it has not. No one using modern tooling for > package management is uploading these file types. > > Even if the statistic of downloads (which actually is valid) doesn't > sway you, maybe this will. Alternatively, maybe you will help maintain > support for these file types in Warehouse? > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
