[Catalog-sig] V4 Pre-PEP: transition to release-file hosting on PYPI

PJ Eby pje at telecommunity.com
Sat Mar 16 03:01:57 CET 2013

On Fri, Mar 15, 2013 at 7:16 PM, Carl Meyer <carl at oddbird.net> wrote:
> Ok, pending agreement from Holger I'll make a change in the PEP to
> explicitly allow clients to make decisions based on either the rel
> attributes or based on hostnames. Would that be sufficient to address
> your concerns?

Yes.  I just don't want to be in a situation down the road where
there's another argument about this on Catalog-SIG when PyPI starts
using a CDN that, "but it says this in the rel and you're supposed to
use that", and I say, "but Carl and Holger said..."  and they go,
"doesn't matter, PEP says"   ;-)

This way, the PEP will be clear that supporting a split of PyPI's
hostnames isn't in current scope.

I am also okay with the PEP allowing *.indexhost instead of just
indexhost as the filtering mechanism, as long as it specifies one
*now*.  (Again, so this doesn't have to be revisited later.)  If
somebody who knows something about CDNs, TUF, etc., needs to weigh in
on it first, that's fine.  I just want to know where things stand.

> Putting the /simple/ API on a CDN isn't quite that easy because it
> currently involves some server-side redirects to effectively make
> project names case-insensitive.

FWIW, easy_install works fine without this.  If a matching index page
isn't found, it checks the full package list.  PyPI's redirection just
reduces bandwidth usage and request overhead in the case where the
case of the user's request doesn't match the actual package listing.
But it could be completely static without affecting easy_install and
tools that use its package-finding code.

More information about the Catalog-SIG mailing list