[Distutils] Reviving PEP 470 - Removing External Hosting support on PyPI

[Paul Moore]

On 30 August 2015 at 05:48, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The devil's in the details, though.
>>
>> * Do I need to use canonical names for packages in my index? Assuming
>> so, what *are* the rules for a "canonical name"?
>
> This is a good point - even if folks are hosting externally, we still
> want them to claim at least a top-level name on the global index.

Although what you say is *also* a good point, my original question was
whether I need to make my links use all lowercase and whichever of
dash or underscore it is that pip treats as the canonical form (I can
never remember). The point I was making is to make sure that people
with an existing non-PyPI file structure can set up an index easily.
They'll quite likely need to build some sort of static webpage for
that (consider a project hosted on something like sourceforge, setting
up an index to replace their current external links on a cheap
provider that only offers static webpage hosting). If it's an older
project, it's quite possible they will *not* use the canonical form of
the project name in their filenames, so they'll need to fix the name
up or they'll get obscure "pip can't find your project" errors.

Regarding your point, though, looking at the wider picture there are
*three* classes of project to consider:

1. Projects registered and hosted on PyPI
2. Projects registered on PyPI but hosted elsewhere
3. Projects neither hosted nor registered on PyPI

(There's also projects in category 1, but with some (presumably
historical) files hosted elsewhere, but I'll ignore those for now, as
for most purposes they can be treated as category 1)

Category 3 could quite easily be massive (private indexes used by
companies, for example) but is irrelevant for the purposes of this
PEP. Category 1 is straightforward - the PEP is a 100% clear win
there, as the overhead of unneeded link scraping is removed.

The problem is existing category 2 projects, and new projects that
want to join that category. We need to ensure that hosting off PyPI
remains a viable option for such projects, which is why it's important
to document how to create an index. But as you point out, we *also*
need to make sure people don't think "what's the point in registering
on PyPI if I'm setting up my own index anyway?" (and hence choose
category 3 rather than category 2).

Maybe there should be a further FAQ in the PEP - "If I'm setting up my
own index for my files, why should I bother registering my project on
PyPI at all?" I suspect this is the real question at the root of a lot
of the objections to the PEP. For people hosting off PyPI, the current
arrangement (ignoring the UX issues) means that "pip install foo"
works for them. We're now proposing to remove that benefit, and while
it's not the *only* benefit of being registered on PyPI, maybe a
reminder of what the other benefits are would put this into
perspective.

Paul