<div><span style="color: rgb(160, 160, 168); ">On Thursday, February 28, 2013 at 1:23 PM, PJ Eby 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 Thu, Feb 28, 2013 at 4:08 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>On Thu, Feb 28, 2013 at 7:00 PM, holger krekel <<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>> wrote:</div><blockquote type="cite"><div><div>To summarize, having pip/easy_install report red warnings and requiring</div><div>to pass a "--htmlscrape=PROJ1,PROJ2" option or so is a good way to</div><div>communicate, removing the ability is not, at this point.</div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>I'm a fan of updating the client side tools (both upload and download)</div><div>to complain if files are not hosted on PyPI, and perhaps even</div><div>requiring switches or configuration settings to say "yes, external</div><div>downloads are OK for projects X, Y, and Z").</div><div><br></div><div>I'm *not* a fan of changing the way PyPI handles external links,</div><div>except perhaps for some of the suggestions PJE made about cleaning up</div><div>some aspects of what PyPI chooses to publish for old releases.</div><div><br></div><div>I'd prefer to leave the "you can't do it any more" step for the next</div><div>generation secure metadata distribution infrastructure (so the</div><div>installation tools will be able to fall back to the legacy</div><div>infrastructure for projects that haven't updated yet).</div></div></blockquote><div><br></div><div>Indeed. I'm hoping that the new tools will make the old ones (e.g.</div><div>setuptools) entirely irrelevant, which is why I'm hammering so hard in</div><div>the PEP discussions on some use cases that eggs do well that wheels</div><div>don't. I don't want people to have to keep using setuptools for those</div><div>use cases. (e.g. simple plugin deployment ala Trac) If the new tools</div><div>handle all of the use cases, then setuptools can die a natural death</div><div>sometime in the next decade or so, so I don't have to be responsible</div><div>for it when I turn old and senile. (It's already turned me grey as it</div><div>is.) ;-)</div><div><br></div><div>For the short run, I anticipate the following steps in the next</div><div>release of setuptools, which I'm aiming to release before PyCon:</div><div><br></div><div>* Default to SSL URL for PyPI</div><div>* Support SSL certificate verification for downloads if the 'requests'</div><div>library is available on sys.path</div><div>* Update docs for easy_install to more clearly and prominently state</div><div>that packages are downloaded from other sources than PyPI unless</div><div>--allow-hosts is used</div><div>* Add an immediate warning to each easy_install invocation (whether</div><div>programmatic or command line) if --allow-hosts is not explicitly set</div><div>to some value in the configuration or command line.</div><div><br></div><div>I'm also considering adding a warning for scraping home page links,</div><div>but at this point in the discussion haven't nailed down how that</div><div>should work. Likewise, I'd like to provide some sort of monkeypatch</div><div>to make register/upload work properly with SSL in older Pythons, but</div><div>I'm not sure I can integrate cert checking there... but at least the</div><div>security will be no worse than using plain distutils. (i.e., it'll</div><div>still be subject to credential theft if someone MITMs PyPI)</div></div></div></span></blockquote><div>SSL checking on upload should be possible, do you want</div><div>a patch? </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>Of course, this release will initially be available as a development</div><div>snapshot, i.e., made available through external links. ;-)</div><div><br></div><div>Future releases I'm undecided about as yet, but certainly if PyPI</div><div>becomes able to pull and cache externally published releases (upon a</div><div>developer's request), that addresses all of my concerns on the</div><div>developer-burden side, and all of the availability/security concerns</div><div>on the other. Setuptools could move to a default --allow-hosts of</div><div>just PyPI, as soon as that feature is available and being used. (And</div><div>if the licensing issues can be worked out, old packages with external</div><div>links could be pulled to PyPI anyway, and the external links removed.)</div><div>_______________________________________________</div><div>Catalog-SIG mailing list</div><div><a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/catalog-sig">http://mail.python.org/mailman/listinfo/catalog-sig</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>