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

[Carl Meyer]

On 10/09/2015 11:18 AM, Paul Moore wrote:
> 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.

AFAIK this is actually just fine currently, it's just not considered
ideal for a hopeful future static-metadata world.

Today, in the all-metadata-is-dynamic world that we actually live in,
the tools aren't able to make any assumptions at all, and just have to
download whatever best-match wheel or sdist they find for a given
package/version requirement, unpack it, and see what it says about its
own metadata (including dependencies). So different binary wheels of the
same package at the same version having different dependencies works
just fine. It's not like any of the tooling would actually know the
difference, since they will only deal with one of those wheels at a
given time.

But of course this dynamic-metadata world prevents the tools from doing
all kinds of useful things (like actually building dependency graphs in
advance so they can do proper dependency conflict resolution), which is
why we want to move towards static metadata. And it's in that transition
that issues like "are different wheels for the same project at the same
version allowed to have different dependencies" become relevant.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151009/f95b25d6/attachment.sig>