This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dstufft
Recipients Arfrever, barry, doko, dstufft, eric.snow, lemburg, ncoghlan, ned.deily, pitrou, python-dev, steve.dower, tim.golden, zach.ware
Date 2015-04-16.22:51:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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.

pip caches downloads by default, many systems are starting to utilize that
cache in order to stop repeat downloads of the same file. This would make it
so that if you had a shared pip cache amongst many archiectures or platforms
(which people are starting to do, especially with sharing caches with virtual
boxes running on their own machines or services like Travis-CI) you'd only have
to download that file from PyPI once ever.

Looking at a few of the top projects on PyPI in terms of download count we

Of those, only really lxml is large enough that adding a second or third or
fourth copy of the .so is a really meaningful increase in size and since we
wouldn't be making a "fat wheel" mandatory lxml could just decide not to build
one. As far as I can tell we don't actually optimize for maximizing the amount
downloading (otherwise we'd use something better than a .zip file).

> 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 are other reasons as have already been mentioned, this is just yet
another reason (and on it's own I'd agree it's not a sufficiently compelling
use case), but when I see a pattern of things which all need the same thing
then that speaks to me that it should live someplace centrally instead of
having each one reimplement it. 

> 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.

I don't care if it gets added as part of this ticket, another ticket, or as
a PEP. I'm just listing where it'd be useful for the kinds of things I do.
Date User Action Args
2015-04-16 22:51:56dstufftsetrecipients: + dstufft, lemburg, barry, doko, ncoghlan, pitrou, tim.golden, ned.deily, Arfrever, python-dev, eric.snow, zach.ware, steve.dower
2015-04-16 22:51:56dstufftsetmessageid: <>
2015-04-16 22:51:56dstufftlinkissue22980 messages
2015-04-16 22:51:56dstufftcreate