<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 23, 2016, at 12:03 PM, M.-A. Lemburg <<a href="mailto:mal@egenix.com" class="">mal@egenix.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 23.08.2016 18:46, Donald Stufft wrote:<br class=""><blockquote type="cite" class="">Since it seemed like there was enough here for a proper PEP I went ahead and<br class="">write one up, which is now PEP 527. The tl;dr of it is that:<br class=""><br class="">* Everything but sdist, bdist_wheel, and bdist_egg get deprecated.<br class=""></blockquote><br class="">-1 on removing bdist_wininst and bdist_msi. If PyPI is supposed<br class="">to retain the status of the main website to go search for Python<br class="">package downloads, it needs to be able to provide ways of hosting<br class="">all distribution types which are supported by distutils, including<br class="">ones which target platform configuration management system such as<br class="">the Windows one.<br class=""></div></div></blockquote><div><br class=""></div><div>I started off at maybe -0 myself for removing format support from PyPI, but reading this rationale for preserving these misfeatures has made me a strong +1!</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The number of downloads is really irrelevant for this kind of<br class="">argument.</div></div></blockquote><div><br class=""></div><div>It's totally relevant. The packaging community has limited resources, and we should use those resources to serve the users that actually exist, not pretend people. The data available from the current system is important to reality-check our assumptions about which sorts of people are in fact real.</div><div><br class=""></div><div>That's not to say that "downloads" is the perfect metric, but it's what we've got to work with, and so we have to pay attention to it unless something better is proposed.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Since the PEP proposes to keep the existing uploads<br class="">around, I also don't follow the argument of reduced maintenance.<br class="">PyPI will still have to host and support downloading those file<br class="">types.<br class=""></div></div></blockquote><div><br class=""></div><div>When the person responsible for the vast majority of the maintenance burden says "this will increase / decrease the maintenance burden" then I tend to believe them. Perhaps this section should be better-motivated in the PEP but I would be _extremely_ surprised if Donald were wrong about this particular point.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">To me, all this sounds a lot like eventually turning PyPI into a<br class="">pip package index, which no longer serves the original intent of<br class="">a Python package index. I think that's taking a wrong turn in the<br class="">development of such an index.<br class=""></div></div></blockquote><div><br class=""></div><div>A "pip package index" - that would be fantastic! Right now, the most confusing thing about the Python ecosystem is the vast diversity of general-purpose installation tools; manual invocation of setup.py, easy_install, pip install, manual Windows installers... if PyPI can centralize all of this stuff around a single installer and get some good, hard and fast de-facto standards around how it's done, that would be much better for user experience. Frankly it would be better for future installers as well, since it would be possible to calibrate for "just works" much better than we can currently.</div><div><br class=""></div><div>But of course, it raises the question: why do you think it is a bad thing?</div><div><br class=""></div><div>In particular, bdist_wininst and bdist_msi (which Twisted supported for a long time, and still builds, so it's not like I don't understand their benefits and history!) are incompatible with virtualenvs, and make development under Windows <i class="">harder</i>, especially as compared to binary eggs. The presence of these builds confuses users and creates more problems than it solves in every interaction I've had with onboarding people onto Python projects in the last couple of years.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">IMO, we should aim to reunite separate indexes such as the<br class="">one used for conda or the win32 index maintained by<br class="">Christoph Golke back into PyPI, not create even more<br class="">separation by removing platform specific formats.<br class=""></div></div></blockquote><div><br class=""></div><div>Absolutely not. This would be a disaster. Conda is a general-purpose cross-language package distribution environment. It hosts packages for C dependencies. If we want to host packages for Conda, we should also be hosting packages for competing projects at that scope of the ecosystem, which means at the very least adding Homebrew, MacPorts, and maybe Chocolatey and NuGet support too.</div><div><br class=""></div><div>In other words, Conda made several different choices about its architecture specifically because it wants to serve a slightly distinct audience from the broader PyPI, and that's fine! We should not feel pressure to standardize and force everyone into a one-size-fits-all model. Conda seems to be doing fine and getting plenty of adoption on its own, and not hurting PyPI's success at all.</div><div><br class=""></div><div>There are several Steam games and Mac apps written in Python too, but I would hope that it's obvious why we should not be running a competitor to the Steam Store, Mac App Store, or Ubuntu Software Center. If people feel that PyPI ought to be a general-purpose CDN for anything vaguely Python-adjacent, we might need a more general anti-goals meta-PEP that specifically rules out consideration of this sort of scope creep for PyPI's design in the future.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">* The only allowed extension for sdist is ``.tar.gz``.<br class=""></blockquote><br class="">Strong -1 on this part. .tar.gz may be a good choice for Unix,<br class="">but it definitely isn't for Windows. Even for Unix, .zip files<br class="">have the advantage of not messing up file ownerships and<br class="">permissions.<br class=""></div></div></blockquote><div><br class=""></div><div>This is the one part I'm still not totally sure about though. .zip has the nice feature of allowing random access (which is why we have 'zipimport' but not 'tarimport', despite 'tar' being the more popular archive format with the general audience). In this case I feel like there's enough usage of both to be worth hanging on to, even if it is a bit more work.</div></div><br class=""><div class="">-g</div><div class=""><br class=""></div></body></html>