<div><span style="color: rgb(160, 160, 168); ">On Wednesday, February 27, 2013 at 3:16 PM, holger krekel wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Wed, Feb 27, 2013 at 14:49 -0500, Monty Taylor wrote:</div><blockquote type="cite"><div><div>On 02/27/2013 02:47 PM, Aaron Meurer wrote:</div><blockquote type="cite"><div><div>On Wed, Feb 27, 2013 at 11:37 AM, holger krekel <<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>> wrote:</div><blockquote type="cite"><div><div>On Wed, Feb 27, 2013 at 19:34 +0100, Lennart Regebro wrote:</div><blockquote type="cite"><div><div>On Wed, Feb 27, 2013 at 5:34 PM, M.-A. Lemburg <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:</div><blockquote type="cite"><div><div>I'm not saying that it's not a good idea to host packages on PyPI,</div><div>but forcing the community into doing this is not a good idea.</div></div></blockquote><div><br></div><div>I still don't understand why not. The only reasons I've seen are</div><div>"Because they don't want to" or "because they don't trust PyPI". And</div><div>in the latter case I'm assuming they wouldn't use PyPI at all.</div><div><br></div><div>And of course, nobody is forcing anyone, just like nobody is forcing</div><div>you to use PyPI. :-)</div></div></blockquote><div><br></div><div>I understood there is the idea to disable external links within a couple</div><div>of months. That does break backward compatibility in a considerable way.</div><div><br></div><div>holger</div></div></blockquote><div><br></div><div>But wouldn't this only be a change in pip/easy_install, not PyPI</div><div>itself? I suppose you could explicitly break the external links by</div><div>having them point to nothing if you are worried about the security or</div><div>if it's some performance issue (that would indeed be a bad</div><div>compatibility break, in case people are using those for other</div><div>purposes). Otherwise, if it's a problem, then just use the old</div><div>version of pip.</div></div></blockquote><div><br></div><div>If we don't remove the feature from pypi itself, then it won't help the</div><div>folks for whom its a problem, because there will be no incentive for the</div><div>folks hosting their software that way to actually upload their stuff to</div><div>PyPI - which means that client-side disabling of external_links is</div><div>fairly likely to never be usable.</div></div></blockquote><div><br></div><div>I can see it's tempting to just try to "force" everyone to upload</div><div>their stuff to <a href="http://pypi.python.org">pypi.python.org</a>. I am very skeptical about this approach.</div><div><br></div><div>There already is a high frustration with the packaging ecology</div><div>in Python. When we remove external links on the server side, installs</div><div>for many people and companies are going to break, no matter what. And</div><div>they would have no client-side switch anymore to make things working.</div><div>Requiring to use older setuptools/pip versions would not help because</div><div>the server information is gone. That'd just increase frustration.</div></div></div></span></blockquote><div>"Locking the bank door will frustrate people when they have to ask the teller</div><div>for their money instead of walking into the vault and grabbing it themselves". </div><div><br></div><div>I'm not asking for this to be shutoff immediately, it will be phased,</div><div>particularly so project maintainers can be made aware that it's</div><div>going away and can upload versions to PyPI to prevent this kind of</div><div>wide spread breakage. Particularly the first phase I outlined for</div><div>PyPI was to disable _new_ links from being added to the /simple/</div><div>pages and keeping the old around. So that _old_ releases still work</div><div>for now, but _new_ ones do not.</div><div><br></div><div>Further more I do have issues for both pip and buildout to implement</div><div>this there as a warning at first, and then move to disabling them by default</div><div>eventually. The goal again to make the fact it's going away a *known*</div><div>fact to give maintainers time to upload packages.</div><div><br></div><div>There will be some breakage, particularly with unmaintained software (but</div><div>if it's truly unmaintained then it's likely to break at anytime when the</div><div>external host goes away).</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>So at the very least using external links needs to be a client-side</div><div>installer choice for a long while and the server needs to offer</div><div>the according information.</div><div><br></div><div>I'd generally prefer to think hard about ways to improve the situation</div><div>without breaking things. Putting simple/ and packaging serving on a CDN</div><div>is one such step and a good idea i think. Establishing a</div><div>signing/verification mechanism is another. Refining py2/py3 dependency</div><div>discovery yet another good one.</div></div></div></span></blockquote><div>Sometimes you need to break things. The goal is to do it with ample</div><div>warning and migration time so that people have a chance to move</div><div>to the new way of doing things.</div><div><br>
</div><div>Again, I am not suggesting we delete all external links immediately, just</div><div>disable new ones. Removing old ones will come later.</div>