<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 23 Aug 2016 at 07:33 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Aug 23, 2016, at 7:25 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> OK, cool - that gives us all the more reason to retain bdist_wininst<br>
> and bdist_msi hosting support. However, I do think it makes sense for<br>
> us to say up front that we'll reconsider that decision if something<br>
> akin to homebrew gains traction amongst developers running Windows the<br>
> way homebrew has amongst open source users running Mac OS X.<br>
<br>
<br>
I still don’t think there’s a whole lot of benefit to retaining them even<br>
now. In the last 30 days, 90% of the downloads of bdist_wininst were<br>
generated by things that I know for a fact to be mirroring clients (almost<br>
all entirely bandersnatch). The next highest source of downloads was coming<br>
from setuptools, at 7%. Over 75% of the downloads from setuptools are for<br>
coverage.py, which tells me that it’s likely being triggered by test_requires<br>
and would be covered by teaching setuptools how to wheel instead.<br>
<br>
For bdist_msi, 96% of all downloads come from things we know to be mirroring<br>
clients.<br>
<br>
For bdist_dmg, 97% of all downloads come from things we know to be mirroring<br>
clients.<br>
<br>
For bdist_egg, 80% of all downloads come from things we know to be mirroring<br>
clients.<br>
<br>
For reference:<br>
<br>
For sdist, 30% of all downloads come from things we know to be mirroring<br>
clients.<br>
<br>
For bdist_wheel, 6% of all downloads come from things we know to be mirroring<br>
clients.<br>
<br>
It’s hard to get per project numbers for these (or at least, it takes a more<br>
complex query than I can manage with my head here). However, I think it’s<br>
pretty telling that when you start looking at other formats, not only is the<br>
primary consumer tools that just indiscriminately download everything from PyPI,<br>
but almost *all* of the consumers of those files are tools that just<br>
indiscriminately download everything. Unless there are users of those mirrors who<br>
follow vastly different usage patterns than what we see on PyPI itself, the primary<br>
purpose of bdist_wininst, bdist_msi, bdist_dmg, etc on PyPI is to consume disk space<br>
and bandwidth via the mirroring infrastructure.<br>
<br>
I’d also like to note, that the numbers above are conservative on what they<br>
consider to be a “mirroring client”. For instance, devpi used to use the default<br>
requests user-agent, and we see downloads via the requests user agent, but did not<br>
count them as mirroring clients because it could be some other script doing the<br>
downloading.<br></blockquote><div><br></div><div>I should also mention I have never come across anyone at Microsoft use the bdist_msi or bdist_winst installers (I've added Steve to this email in case my experience is wrong). Everyone I have encountered either uses conda or pip+wheels (hence why I keep poking the sdist and build API ideas as I want to give Christophe Gohlke something else to do with his time than provide wheels on Windows).</div></div></div>