PEP 752: Implicit namespaces for package repositories

[ofek (Ofek Lev)]

Since last time, I landed a PR which did the following:

1. Expressed the use case for open/restricted namespaces in the motivation section.
2. Made it clear that the current automatic protection against typosquatting used by PyPI is insufficient.
3. Added examples of attacks to the appendix.
4. Fixed versioning of the JSON API.
5. Rejected the idea of encouraging projects to maintain their own package repositories.
6. Rejected the idea of fixed top-level prefixes used for reservations.
7. Rejected the idea of using DNS.
8. Expressed in the rationale that using PEP 541 requests in addition to this proposal would minimize risk to users.
9. Added a community buy-in section enumerating feedback from relevant projects and communities.

@woodruffw

@ofek

until somebody writes a proposal for explicit namespaces which is implied by this PEP.

I might be misunderstanding, but what would this have to do with explicit namespacing? I think the “known prefix” approach is similarly implicit, in the sense that it’s composed of pre-existing syntax.

It’s not a very robust heuristic but in my mind I’m mapping all feedback that is not in favor as a proponent of explicit namespaces.

@ncoghlan

@woodruffw

To summarize the idea again, for continuity: rather than allowing grants of any top-level prefix (such as foo-bar- or foo-), namespaces would instead be defined as grants within a fixed subset of well-known prefixes.

Disallowing top level namespace grants feels like a PEP 755 (PyPI policy) topic rather than a PEP 752 (client & server API implementation) topic.

I agree but didn’t want to have a rejected ideas section in both proposals so I put it in 752.

@takluyver

@ncoghlan

Within a restricted grant, they offer a way to carve out a prefix for plugins and third party solutions.

Thanks, that makes sense. But coming back to my point above, I think this is better represented as a setting for grants rather than a whole separate type. I.e. once you get a top-level prefix, you can make a sub-prefix like foo-contrib-, then you can set that to allow either anyone to upload, or a limited set of people, but different than the parent foo- prefix.

I think the reason ‘open namespaces’ was a separate grant type in the first place is so that ‘restricted’ namespaces could be exclusive to paying customers. I think that’s a mistake, as discussed on the PEP 755 thread, and this is why I’m pushing back on them being a separate type.

The concept of open/restricted (final naming) has, since the very first draft, being a setting on a grant and not a separate type of grant. I’m not quite sure where that came from?

I don’t want to go into it on this thread because it’s about policy but the original reason for encouraging grants for community organizations to be open was for two reasons:

1. Projects from such organizations are in most cases comprised of at least some packages maintained unofficially and therefore this was a preventative measure to avoid the possibility of closing an ecosystem.
2. In practice it will be significantly easier to get an application accepted for such organizations than expected which may exacerbate 1. to a level where it happens regularly and taints the perception of the Python community as a whole.

@pf_moore

I agree that expecting open source projects to set up their own server is an unwarranted cost to impose. But for commercial organisations (ones willing to pay for a closed org namespace) it is IMO a reasonable option to suggest. The fact that organisations don’t do this already suggests that there are other factors in play, although the cynic in me tends to think “organisations doing nothing and hoping open source will fix their problems for free” is the root cause here…

I think the cynical view is not correct and I’ve added a rejected idea Encourage Dedicated Package Repositories.

@brettcannon

@mikeshardmind

I’m still very against string prefixes and placing corporations into a tier above volunteers, especially when that will increase the load on pypi admins/support.

I would assume corporations would be paying a fee high enough that the PSF would be able to higher enough people and then some to handle any additional load.

PyPI without a doubt, and likely packaging tooling after a year or two.