Follow-up from the previous thread: PEP 752: Package repository namespaces
This is now only related to policy and operational choices for PyPI.
thanks for creating a better comprehandable proposal for this aspect.
thereās no rationale given why corporates need to meet lower standards than other social entities. imo that is deeply undemocratic. given your (unmentioned) affiliation with Datadog i find the introducing example in PEP 752 irritating. it looks like youāre pushing an agenda for a specific interest group and are too biased for a proposal that considers all interests in the community.
1 Like
I have alternative questions for you which will help me answer yours:
- Do you think individuals should be able to reserve namespaces at will? Why or why not?
- What are social entities, exactly?
I did mention here that we are donating significant engineering time during the last quarter of this year. I donāt know of another PEP that had to make such a disclaimer. I assume none do because proposals would never be accepted if they didnāt benefit the community as a whole.
As far as the example, I think itās a quite representative one of the dangers I express in that section. Would you prefer I went all in on talking about packages of cloud providers who are owned by mega-corps with 100x revenue?
Please understand that this perspective ignores the fact that this feature has been requested for years and that many community projects that I outlined in PEP 752 desire this feature as well.
5 Likes
excuse me, i formulated my criticism based on a misinterpretation. as a non-native English user i wasnāt aware of the distinction between ācorporateā and ācorporationā. i assumed both meant what the latter actually does.
For example, while itās reasonable to grant a namespace to a startup or an existing company with a new product line, itās not as reasonable to grant a namespace to a community project that doesnāt have many users.
maybe the examples could also mention a bunch of academics with a special interest or other communities around non-profit projects.
i do neither regarding PEPs, but generally the statement of relevant affiliations and potential conflicts of interest in normative documents are key to transparency.
4 Likes
This is the case when binding decisions are being made in private meetings that arenāt subject to external review. Itās different when not only the final decisions, but every draft, and every discussion point raised are all happening in public. (Although in this case, affiliations were specifically discussed in the original PEP 752 discussion thread, and we adjusted the choice of PEP delegate accordingly)
1 Like
These two excerpts from the PEP are deeply disturbing:
Only organizations have access to the page for submitting grant applications. Reviews of corporate organizationsā applications will be prioritized.
For example, while itās reasonable to grant a namespace to a startup or an existing company with a new product line, itās not as reasonable to grant a namespace to a community project that doesnāt have many users.
Core Python itself has always been a mostly-volunteer project. Many prominent libraries in the larger Python ecosystem are, partly or fully, volunteer-maintained, and not affiliated to a particular ācorporate organizationā. PyPI itself has, for most of its time, been volunteer-driven as well.
While there is of course a corporate presence in the Python ecosystem, it does not have the same fundamental role it plays in e.g. the Java world.
Not only this proposal is creating an inequality in favor of the powerful, it does not even have the excuse of reflecting the actual contribution dynamics in Python communities.
11 Likes
What criteria do you view as reasonable for accepting an application for a community project to reserve a finite resource? As a follow-up Iām curious your answer to this one as well:
As a quick note, Iām wondering if substituting āpaidā for ācorporateā might make some things sound slightly less jarring. So for example:
Only organizations have access to the page for submitting grant applications. Reviews of corporate organizationsā applications will be prioritized.
could be rephrased (with some editorializing, which is just an illustration, I donāt consider mine great wording either):
Only organization accounts have access to the grant application form. Paid organization accounts receive priority in the reviewing queue. [something like āas a benefit of payingā could be inserted, but makes it sound quite clunky]
Thereās nothing to stop an organization that could qualify for a free account to pay for one, perhaps as a way to show support to the Python ecosystem. For me it just kind of takes the edge off using the term ācorporateā.
2 Likes
I have a similar concern around inequality. To give a reasonably well known example, @barry has various projects under the flufl prefix. This proposal allows a company to come along and claim that prefix, preventing Barry from creating new projects with that naming convention. And thereās no provision in the proposal for Barry, as an individual developer, to defend himself against such a possibility by either registering that prefix himself, or otherwise asserting his intention to use that prefix for future projects.
To be clear, Iām only using @barry as an example here. I have no idea what his view is on this proposal, or whether he shares this concern.
It may be that the answer is to simply assume that the PyPI admins will be reasonable. But thatās frankly not very scalable, and itās not at all obvious that fixing any mistakes that might still happen would be practical.
10 Likes
I donāt think any criteria is reasonable here whether for corporate, community, or individual use. At least, not in the form proposed here. names are already a finite resource, to cut off naming by entire prefixes will at some point result in the ānaturalā name for a project being unavailable.
- There is no improvement on signaling that a package is official to users. (users wonāt see any UI only elements that would indicate a grandfathered package when installing packages, only when visiting the project page on an index that chooses to display information for this, and the package owner is already visible there)
- There are major downsides to existing packages and existing naming conventions.
- This reeks of potential for abuse and reminds me of some of the events that kicked off the whole left-pad incident on npm by placing companies above volunteers.
I donāt think the prefix-based implicit namespaces have made a strong case that they solve any problems, and I donāt think the reasons to not have actual namespacing by user/org imply that having this instead is good on itās own.
4 Likes
The exact same criteria that would be used for corporations.
I have no idea, as I canāt think of any individual for whom reserving an entire namespace might make sense.
Itās reputational I think. As @pf_moore points out by example:
flufl is a silly prefix, but one nonetheless that Iāve adopted. While I donāt expect it would ever be in conflict with an organization account, I can easily imagine that other folks who similarly use prefixes to collect their packages could someday find their prefixes locked out due to org account claims.
PEP 541 already has some policy about project name conflicts where IP infringement is part of the equation. Namespaces seem at least somewhat related to this. Is there a way to build on the 541 policy for also reconciling namespace disputes?
2 Likes
Root grants given to community projects should only be open but is ultimately up to the reviewerā¦
To pick up a discussion from the previous thread, why is this? I think we established that there are community projects which would like to have restricted prefixes. The PEP still seems to say that they are wrong to want that, except maybe in some rare cases - with no indication of what those are.
The only rationale I can see is to incentivise people to pay up. But putting a long-desired security feature (restrictions to make typosquatting harder) behind a paywall feels like a spectacular own goal.
Generally speaking, reviewers should be more tolerant of corporate organizations that apply for grants for which they are not yet using.
For example, while itās reasonable to grant a namespace to a startup or an existing company with a new product line, itās not as reasonable to grant a namespace to a community project that doesnāt have many users.
Again, itās hard to understand this as anything other than āgive us moneyā. Startups fail, pivot or get bought out all the time. Big companies can cancel products with abandon - doubtless many more before launch. Yet this seems to give them near complete freedom to restrict prefixes to other people, potentially in perpetuity - the āgrant removalā section currently has no mention of clawing back a prefix without the agreement of the owner, even if thatās a company that no longer exists. Why are corporate organisations held to so much lower standards than everyone else?
There is no page to view all active namespace grants because this has the potential to leak private information such as upcoming products.
Itās taking some effort not to descend into snark. Companies can block off a prefix and the rest of us donāt even get to see that, because it might spoil their reveal if someone can see the name? What happened to transparency & openness?
If weāre really concerned about forcing companies to reveal a name theyāre planning for a future project can we at least make this time limited, e.g. you can reserve an invisible prefix for 1 week, and if you havenāt uploaded anything in that time, youāve lost the reservation. Or charge handsomely for the privilege of saving an invisible prefix for an upcoming product; for the companies that care about this, I imagine a few thousand dollars a month is peanuts.
14 Likes
Perhaps prefixes should be linked to defensible trademarks, rather than being arbitrarily selected by whoever requests it?
That at least clearly means that someone trying to claim flufl.* is explicitly accusing @barry of trademark infringement, for which there are (unfortunately, usually prohibitively expensive) mitigations. It also means that community projects are more likely to be covered, since many foundations are willing to play the role of a trademark āownerā.
I suspect that itās easier for PyPI to play a neutral role here: if a request for a namespace is made, all existing package owners in that space are emailed and have an option to contest their use of the trademark. If any do, there is no reservation made and the requester is told to sort it out first directly with all the package owners and then request again. (Which a big enough and sufficiently motivated organisation will doā¦ but could do it already if they wanted.)
6 Likes
What if we went one step further and based prefixes on reversed domain names? So com.google.* could belong to Google, org.jupyter.* to Jupyter, and so on.
Obviously this would be more of a shift in our conventions than registering google-* or jupyter-*, but on the plus side:
- Itās a pattern already familiar in many other ecosystems (Java packages, apps on Android, Mac & many modern Linux apps), so weāre not starting from scratch.
- Domain names are exclusive, whereas trademarks can overlap.
- This could allow for automated or semi-automated registration of a prefix, based on setting up a particular DNS entry or static file on the domain you own, potentially reducing the load on PyPI admins, who everyone agrees are overloaded.
- These are already valid package names, so it shouldnāt need major changes in tooling.
- But theyāre not commonly used, so the issue of pre-existing packages conflicting with a restricted namespace is smaller (albeit not totally gone).
4 Likes
I donāt like this proposal (PEP 755 in particular, and PEP 752 in general as well). At first I thought it was clever and I could recognize both good intentions and easy implementation (of PEP 752). But the policy aspects were raising some flags, I was not sure of the color yet. Now I know the flags are at least reddish. Why? I think because it is changing long-established rules. The rule was simple: first arrived, first served. Just like on basically any other online service. Now I do not understand exactly what the rules would be but they donāt seem fair. For example I canāt help but think of ānail housesā. I have not digested the whole implications of this proposal yet, and I hope I am wrong but it does not give me warm fuzzy feelings. Letās seeā¦ : )
2 Likes
Iām going to address individual points later tonight but I would encourage those who dislike the idea to consider the motivation and offer alternatives that cause as minimal ecosystem disruption as the current proposal, besides doing nothing 
Normally, I would agree with this, but here there is obviously money involved, so: ānoā. ; )
Feels like the ecosystem is fine to me. It seems to me like it is mostly companies that are uneasy with the current state of things. Maybe I am wrong. I think this proposal could use more references to actual complaints from the community (corporate or not) that this change is necessary.
3 Likes
So I should just enumerate a bunch of examples in the appendix like this? Manage projects with namespaces Ā· Issue #2589 Ā· pypi/warehouse Ā· GitHub
2 Likes
My 0.02c as a community member: I think the security benefits of package namespacing tend to be (slightly) overstated. At the same time, I think namespacing is a good idea for Python packaging: on the most basic level doing implicit namespacing preps us to eventually do explicit namespacing, which in turn:
- Frees up the overall flat namespace and eliminates the āeconomicsā of obtaining a catchy/memorable name (as well as the incentive to mass-squat packages, like @ofek just mentioned)
- Reduces the administrative burden on PyPI to administrate the namespace and perform routine ownership transfers via PEP 541
These two reasons alone are (IMO) more than sufficient justification to pursue both implementation and policy PEPs for index namespacing.
(Iām paid to work on Python packaging, but I have no financial interest in these PEPs or in namespacing more generally.)
5 Likes