[Catalog-sig] Deprecate External Links

[Nick Coghlan]

On Thu, Feb 28, 2013 at 6:27 AM, Donald Stufft <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.

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)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia