[Catalog-sig] Deprecate External Links

[Donald Stufft]

On Thursday, February 28, 2013 at 1:39 AM, Nick Coghlan wrote:
> On Thu, Feb 28, 2013 at 6:27 AM, Donald Stufft <donald.stufft at gmail.com (mailto:donald.stufft at gmail.com)> wrote:
> > Sometimes you need to break things. The goal is to do it with ample
> > warning and migration time so that people have a chance to move
> > to the new way of doing things.
> > 
> > Again, I am not suggesting we delete all external links immediately, just
> > disable new ones. Removing old ones will come later.
> > 
> 
> 
> This thread is long enough that I'm not sure on where to weigh in.
> Here seems appropriate enough.
> 
> 1. The next generation metadata infrastructure will NOT support
> external hosting of files indexed on PyPI - if you don't upload the
> archive files to PyPI, they won't be included in the next generation
> metadata. If you want external hosting, you will need to run a
> separate index (this is similar to the yum model - you can host files
> wherever you want, but you need to run "yum createrepo" yourself to
> generate the metadata, and instruct users on how to get their
> installers to retrieve your metadata. The big difference between PyPI
> and the yum model is that the default index still won't be curated at
> all, so there's no review process to get through if you want to use
> it, thus less need for external hosting).
> 
> 2. Near term, with the current generation infrastructure, I think it's
> better to approach the problem *very* gently. Our political capital
> with users is low at this point, and we need to prioritise what things
> we want to make people angry about (whether or not we consider their
> anger justified is completely irrelevant). This proposal is for a
> transition that would take months. Since I want to have the next
> generation metadata up and running within months *anyway*, that means
> this strikes me as primarily a distraction from fixing the problem
> properly.
> 
> 

I'm glad the next set of Metadata won't have external links, however
even if it showed up tomorrow it's going to be a long time until
people are completely migrated to it. Furthermore you estimate
months but the first phase will have positive benefits right away, namely
that it will prompt people to start uploading their packages better increasing
the security and reliability of the current system. And finally while I'm
glad to see forward movement It's been said before not to bother
making a fix to the existing system because X was going to happen
soon, in the past i was distutils2/packaging, now it's PEP426/packaging.
While I have every hope and I believe it will happen this time, the
past has made me worry about holding off on good incremental
improvements to the current infra. 
> 
> 3. Various other problems raised in this thread will only be fixed
> with next generation metadata that the automated tools can *rely* on
> rather than having to guess the intended semantics. That's why PEP 426
> is now explicit about pre-release handling, and why it makes version
> specifiers like (for example), "Requires-Python: 2.6" exclude Python 3
> by default. (although the thread does raise an interesting question of
> whether or not you can cleanly specify dual Python 2 & 3 support given
> the current state of PEP 426)
> 
> 

Pre release handling doesn't require anything new to handle
(https://github.com/pypa/pip/issues/820) requires-python will be that's
a separate issue really. 
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan | ncoghlan at gmail.com (mailto:ncoghlan at gmail.com) | Brisbane, Australia
> 
> 


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