On 16.04.2015 20:17, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
>> Well, it's even more wasteful if you have to download 100MB wheels
>> with all the different platforms when the dedicated wheel would just
>> need 1.5MB.
> 
> I think it's going to vary greatly based on how many platforms you're attempting to support and how big your .so's are compared to the rest of the Wheel. You can also mix and match, do a single bundle for the most popular platforms (which will mean that you're almost always serving out of cache) but then do individual wheels for the less popular platforms to keep the file size of the "main" wheel from bloating up with a bunch of .so's for platforms which are unlikely to be needed very often.

Whatever you do, you're still going to force all your main users to
download things they don't need, so I don't see the argument of
optimizing downloads or caches.

> Another possible (future) benefit - Right now we have executable zip files, but they can only reasonably contain pure Python files. There are rumblings of making it so it's possible to import .so's from inside of an executable zip file. If you bake in the platform ABI into the .so file name, it would mean in that possible future you could have a single executable zip file that just works across multiple platforms as long as you already have Python installed.

Since you need special support for such ZIP files (either using dlopen
hacks or temporarily extracting them), you might as well deal with
the platform dependencies in that handler. No need to force the
platform tags on all your .so file for no apparent reason.

There's a very real use case for having multiple Python versions
installed which was the motivation for the PEPs I quoted, but this
development is one of those YAGNI features only very few people
will ever need.

> I do agree that pretty much every place someone would want to do this, could possibly be implemented by having it look inside a per platform directory (you could implement fat wheels for instance by having platform sub dirs, same with a single executable zip file), however doing that causes duplication because every place you deal with .so's then need to deal with the question of platform ABI and have to come up with their own solution to it, instead of having a central solution which is managed by Python itself and can be re-used by all of these situations.

I'm not saying that having a central solution is wrong. All I'm
saying is that the implementations on this ticket are not within
the scope of the ticket and instead need a proper PEP to see where the
real use cases are and whether this particular way of doing things
is a way we all want to go.

We now have four ways of describing ABI flags in Python (well, actually
even more, since Linux, Windows and OX S use different approaches for
the platform ABI .so flags). This can't possibly be a good approach.

I can already see all the different OS vendors creating
their own little platform triplet extensions. In the end, it's rather
likely that an extension compiled with eg. openSUSE won't run on Fedora or
Debian anymore and vice-versa; and one compiled with vanilla Python
probably won't run on Apples' Python anymore for similar reasons.
Not a good perspective. This is going to make distributing binaries
harder, not easier.