On Thursday, February 28, 2013 at 1:23 PM, PJ Eby wrote: > On Thu, Feb 28, 2013 at 4:08 AM, Nick Coghlan <ncogh...@gmail.com > (mailto:ncogh...@gmail.com)> wrote: > > On Thu, Feb 28, 2013 at 7:00 PM, holger krekel <hol...@merlinux.eu > > (mailto:hol...@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@python.org (mailto:Catalog-SIG@python.org) > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig