[Distutils] PEP470, backward compat is a ...

[Paul Moore]

On 16 May 2014 20:27, Carl Meyer <carl at oddbird.net> wrote:
>>> Or, thirdly, Paul's proposal could solve this, if PyPI automatically
>>> generated an "external legacy index" for any packages that haven't
>>> generated their own external index URL by a certain date. Really in a
>>> way this is similar to Holger's proposal, except it uses
>>> external-indexes instead of verified-external-URLs, and is again a bit
>>> more explicit about what's going on (at the cost of requiring more
>>> adjustment from users).
>>
>> It’s an interesting idea. I’d have to think about it. There is of course nothing
>> stopping anyone from doing this and shoving it on pythonhosted.org.
>
> The part that not anyone could do would be auto-populating the
> discoverable external-index-url metadata with this auto-generated index
> url, for inactive projects. That would require PyPI admin intervention.
> That part is key, because it's the only way the user of such a package
> ever finds out about this new external index for it.

I'm not sure I understand this. What I was proposing is entirely
doable by anyone. Simply scrape every
https://pypi.python.org/simple/XXX page looking for external links.
(You'd need to do the same link chasing and scraping as pip does, to
discover the actual downloadable file URLs). Bung them all on a simple
index page. Do that once and publish the result. That's it. It's a
one-off exercise, I explicitly *don't* propose refreshing the page
after it's created.

Oh, wait - you mean putting a link to that static index page on the
project simple index page for any project we index here? Yes, you
can't do that, but I never intended that we should. My assumption was
that if people wanted a legacy package, they would currently be using
some combination of --allow-external and --allow-unverifiable. We just
tell them "If you're using those flags, and the project you depend on
isn't showing a proper external index, you can use the legacy index to
make things work again - but it's not any more secure or trustworthy
than the --allow-XXX flags. You should do your own security and
supportability review if you care."

Paul