[Catalog-sig] Deprecate External Links

Donald Stufft donald.stufft at gmail.com
Thu Feb 28 23:00:23 CET 2013


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

SSL checking on upload should be possible, do you want
a patch? 
> 
> Of course, this release will initially be available as a development
> snapshot, i.e., made available through external links. ;-)
> 
> Future releases I'm undecided about as yet, but certainly if PyPI
> becomes able to pull and cache externally published releases (upon a
> developer's request), that addresses all of my concerns on the
> developer-burden side, and all of the availability/security concerns
> on the other. Setuptools could move to a default --allow-hosts of
> just PyPI, as soon as that feature is available and being used. (And
> if the licensing issues can be worked out, old packages with external
> links could be pulled to PyPI anyway, and the external links removed.)
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
> http://mail.python.org/mailman/listinfo/catalog-sig
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130228/d0e1e1d9/attachment-0001.html>


More information about the Catalog-SIG mailing list