Marc-Andre Lemburg added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22980> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
