[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Paul Moore]

On 9 October 2015 at 18:04, Chris Barker <chris.barker at noaa.gov> wrote:
> 1) what in the world is a "source wheel"? And how is it different than an
> sdist (other than maybe in a different file format.

A "source wheel" is the proposed name for a to-be-defined replacement
for sdists. For now, you can think of "source wheel" and "sdist" as
the same.

> 2) Is it indeed "OK" with the current PEPs and tools for different binary
> wheels to have different dependencies? This would be the example of, for
> instance the Matplotlib binary wheel for Windows depends on a py_zlib,
> whereas the binary wheel for OS-X relies on the the system lib, and therefor
> does not have that dependency?
>  (and has anyone worked out the linking issues so that that would all work
> with virtualenv and friends...)

It's not *currently* OK for different binary wheels to have different
dependencies. At least I don't think it is. It's basically not
something that as far as I'm aware anyone has ever considered an
option up till now, and so it's quite likely that there are
assumptions baked into the tools that would break if different builds
of (a given version of) a package had different dependencies.

One of the proposed approaches to binary dependencies (the one I've
been referring to as "the pyopenblas approach") is based on the idea
that different wheels could have different dependency metadata. I've
tried to enumerate the questions that need to be looked at if we were
to go down that route, but to my knowledge, no-one has yet either
tested how well things would work if this happened, or audited the
code for problematic assumptions. So it's a possibility for the
future, but like many things it depends on someone doing the work to
make it happen (and as far as I know it's mostly the numpy community
who have the need, so I assume someone in that community would need to
move this forward).

Paul