[Distutils] Deprecating little used file types/extensions on PyPI?

[Robert Collins]

On 21 August 2016 at 15:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 21 August 2016 at 08:40, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>>>
>>> If we're going through all this trouble, isn't it better just to jump to .zip files like every other distribution format in existence?
>>
>> Yes. :-)
>
> zip is popular for *user facing* distribution formats, where the file
> format is exposed directly to end users, and end user applications
> (e.g. zipimport, ODF).
>
> That's not where tarballs shine, so it's not where they show up: tar
> is a backend infrastructure format, used for tool-to-tool
> communication, rather than user-to-user.
>
> The trajectory of distutils-sig for the past few years has been
> towards a world where sdists are primarily a tool-to-tool format for
> data interchange between publishing tools (e.g. twine), installation
> tools (e.g. pip) and redistribution tools (e.g. conda, RPM, deb,
> buildout), with wheels (and potentially eggs, or an equally zipimport
> friendly future derivative) being the preferred formats for working
> directly with Python software in a destination environment (whether
> that's a system integrator's build farm, a production software
> deployment, or a Python user's local system).

Jar's are zip's (~= wheels). *source* jars are also zips. (~= sdists).
I'm struggling to think of any two ways that .tar.gz is better than
.zip. The compression is ~=. .tar.lzma and friends can be radically
smaller whereas .zip has per-element compression, so thats one way,
but .tar.gz has no other benefits (it has other differences, but none
are relevant in the context of the sdist use cases AFAICT).

As far as the switching consts Donald raises, here's my take:
 - we're going to break a lot of peoples workflow no matter what: 10%
of a lot is a lot.
 - all setuptools in the while /can/ produce .zip's AIUI, so the
issues w.r.t. the long tail of Linux distros is entirely
uninteresting: the folk depending on the default behaviour will need
to be explict - but thats going to be the case for *everyone* [because
setuptools on windows is inconsistent with setuptools on Linux]: we
are basically telling everyone they have to hardcode to .zip until the
long tail of existing installs *everywhere* has gone away.
 - unzip and friends are as available on Linux distros as tar is.

tl;dr: I think standardising on .tar.gz would be a rather shortsighted
thing to do, given how many Windows users Python has and how much of a
different supporting .zip makes for workflow on that platform - with
no negative impacts on any other platform.

-Rob