On 30 August 2015 at 05:48, Nick Coghlan <ncoghlan@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