PEP 752: Package repository namespaces

Packaging
102

After reviewing the discussion here, I’m concerned that there are two implicitly related concerns leading to a lot of cross-talk that doesn’t benefit progress: The technical design and the policies/user-experience.

Recalling that PyPI is an implementation of the PEPs that define a Python package index, I support a reduction of scope of the PEP draft to propose the technical details such as URL formatting, naming specifications, client/installer interaction, and any necessary API changes to implement namespacing. I don’t recall any previous PEPs which establish user-interface elements for a package index.

Details around policy of how namespaces are granted, displayed, and the impact on existing projects will have a more concrete footing once a technical design is established and the resulting decisions can be codified in PyPI’s implementation.

15 Likes
103

I just saw PEP 755 pop up on my RSS feed: Implicit namespace policy for PyPI

And so I’m late to this discussion, and still have not read all of it.

One thing which strikes me about the PEP and 752 and this discussion is
that it seems quite aimed at organisations (and more loosely,
communities) and pretty much doesn’t mention individuals.

I did see Donald Stuft’s concern about renaming existing projects, and
also Ofek’s statement that existing packages would be unaffected.

So I thought I’d raise the individual author side of things.

Where does the individual sit here, with their existing packages?

Background:

I’ve got some packages on PyPI, all under cs.*: Profile of cameron.simpson · PyPI

That prefix happens to be short enough to be excluded from PEP 755
anyway (which says 3 or more). But:

  • I deliberately chose the prefix as short, easy to type, and eschewing
    the whole “pick a very cool sounding top level name for every package”
    issue
  • it’s worked (for me) quite well for some years, with nobody else
    choosing that particular prefix on PyPI

Recently a company in Germany contacted me. They’re also using a suite
of cs.* names in their private repo (it accords with their company
name initials, not unreasonable), and discovered that their names
collide with a few of mine, causing them some build issues.

They asked if I’ve step out of the cs.* namespace. (I was reluctant,
and still am.)

I proposed that neither of us “own” that prefix, and instead we’d just
coordinate to avoid conflicting names.

Which we’re doing. I think. I dropped one of my conflicting names and
now keep a list of their packages to check against in my build/publish
workflow.

What are people’s thoughts on a namespace grant which, for want of a
term, “occludes” some existing individual’s published names? Is such a
grant just not made?

1 Like
104

Thread will be opened soon, not quite ready :slightly_smiling_face:

Can you please elaborate?

105

Ignoring PEP 755’s 3-character name lower limit for the sake of the example (since I’m using cs.*), what happens if the namespace cs were granted to some org? Specificly, what would be the status of my packages, and any new ones I would want to make, which would of course also want to follow my current naming practices?

Do I need to rename my existing names? (I gather this is not the case.) I’d hate this one.

Are my packages (which I assume are unrelated in purpose to the purposed of the org receiving the grant) now “unoffical uses” of the namespace? Do I block use of my existing (meaning “published”) names by the org?

What happens if I want to publish a new cs.newname package? (For me, this happens not infrequently as small things cross that “getting stable and maybe useful to others” boundary). Should I coordinate with the org, even though it isn’t to do with them or for their project’s goals? Am I effectively forbidden from new cs.* names because I’m not in the org which has the grant?

Should I myself apply for a namespace grant? Probably as a free range grant where I just want users of it to coordinate enough to not tread on each other.

Again, I gather for me this isn’t really the case because my prefix is very very short, but I can well imagine someone like flufl being affected.

3 Likes
106

If the organization has not made the namespace shared then you cannot make new packages using that prefix (unless you joined the organization).

Nope!

Yes.

Yes, they gain no privileges over your existing projects that match the prefix.

It depends on the projects in question. If the only relation is that they happen to come from you as an individual (kudos for pseudo-claiming Computer Science :smile:) without some sort of community aspect or shared purpose then the application would be very unlikely to be approved. Also, please keep in mind that only organizations can apply for a namespace.

107

Right. Which I am not, which led to my queries.

Does the presence of existing packages prevent (or reduce the chances) of an org being granted a namespace which would encompass those existing packages? Do the existing package authors get queries as to whether they’re part of the org, working to the same cause as the org (thinking of things like 3rd party django plugins, etc), not working on things related to the org?

1 Like
108

Reduces the chances in relation to the number of users; it’s all about the users. For example, if there were multiple packages starting with foobar without very many users and then FooBarCorp wanted to start publishing with that prefix then that would very likely be approved. On the other hand, if DjangoCorp tried to claim django there would be no shot.

That’s a very good question, thanks! I’m going to add a policy that new grants that match existing packages will get an email notification sent to the owners.

2 Likes
109

Since last time, I have made the following changes:

  1. Extracted all policy, operational and UI recommendations into a separate PEP and renamed to Implicit namespaces for package repositories.
    1. Removed the concept of grants types; root grants are now just grants. Repositories may add the concept of child grants but that is not discussed.
  2. Switched the shared/private terminology to open/restricted; this is final.
  3. Officially specified the concept of organizations as entities that own projects and have various users associated with them.
  4. Made it explicit that this proposal is for repositories that allow creation of projects e.g. non-mirrors.
  5. Replaced the namespace.owners key in the API with namespace.authorized to eliminate client-side logic.
  6. Made it explicit that packages starting with a prefix that is owned on one repository does not convey additional trust when coming from others.
  7. Made it clear that namespaces that were previously claimed but are now not should be eligible once again for claiming by any organization but the decision is left to the repository.
  8. Removed shell syntax argument from the organization scoping rejected idea.
  9. Made it clear that implicit namespaces as defined by this PEP would be a prerequisite for explicit namespaces (new package syntax) because the latter would still have to play nicely with the current flat namespace.
  10. Incremented the JSON API version from 1.0 to 1.1.
  11. Added a new namespace endpoint.
  12. No longer expose the owner of projects in the API because organization names are separate from users (at least on PyPI). Therefore, it would cause confusion due to the owner field of projects being different than the one for namespaces.
  13. Allowed repositories to have hidden namespaces to enforce upload restrictions.
  14. An email is now sent to the owners of projects to match new grants that are not owned by the organization receiving the grant.

New threads:

Let’s discuss in the new threads, thanks everybody!

5 Likes
111

Closed topic per request.

2 Likes