PEP 755: Implicit namespace policy for PyPI

I’ve read the discussion and I find it really interesting, and would like to explain how it looks like from a non-corporate, big open-source, vendor-neutral project that might be good user of this - Apache Airflow (also mentioned by @ofek in the PEPs).

There are two distinct issues discussed here, I think:

  1. whether it’s ok to use implicit namespace as defined by prefix in package name or whether it should be a new feature of packaging to somewhat associate the packages with it’s parent organisation

  2. whether it’s ok to get it as a “mostly paid” feature for big-gish organisations (I assume and this was suggested by me some time ago that some organisations - like Apache Software Foundation which are effectively open-source non-profit stewards should also join the club.

Since I am not very active here and have no merit to make or lobby for decisions, I will rather explain how it loooks like from our side - but of course the decision what to do is in the hands of the people who have merit in PSF/packaging.

For 1) I have a bit mixed feeling.

On one hand fior years we have adopted such schema: apache-airflow-providers-PROVIDER_NAME is the standard way how we name our provider packages (we have over 90 of those). And whenever we add a new integration, we always have this moment of thrilll - “is the package already taken by someone?”. We had recently an example with apache-airflow-providers-teradata that was (2 years ago) created by somoene from our community who had no idea that this is somewhat confusing. And when Teradata company actually contributed their provider to Airflow, we had a bit of a problem - how to name it. Fortunately this was a good member of the community and his provider was not really used by anyone and he agreed to transfer ownership, but I easily imagine a situation where someone is proactively pushing malware packages with “apache-airflow-providers-NEW_FANCY_INTEGRATION” before we manage to reserve it (we typically reserve package names when we start discussing adopting them via the “organisation” feature). It’s a matter of someone being malicious against us - for whatever reason and doing it first - our naming convention is known and our users know what to expect as a name there.

And having “apache-” upfront is a soft (not enforceable for now) requirement of the Foundation. One of the important aspects for the ASF is trademark policy Apache Software Foundation Trademark Policy - a lot of the policy is about making sure that our users can easily distinguish an “ASF” released and maintained code from a “3rd-party” managed code. It’s all about trademarks and brand. And Trademarks and Brand are the only way ASF can protect its communities and assets and the main mechanism the foundation can control their right. Simply because of Trademark and Brands it can build sustainable communities, that can be stronger than vendors that might want to take ownership/control of some of the open-source projects of the ASF.

And ASF has informal (and not enforceable) convention during incubation of projects that the package names should be “apache-” (where PMC is the project) - precisely to avoid the confusion.

So having PEP 755/752 implemented would make our life way easier to follow the convention.

But on the other hand I see that there is a risk of abusing it by reserving some obvious and “precious” chunks of the namespace. I am not sure if just “paying” is enough of a gate. Which leads me to problem 2)

  1. What criteria to apply - I personaly like what has been proposed earlier in the discussion - base it on actual trademarks registered by the organisation that wants to reserve the name. This has some obvious problems (which country? trademarks for what scope ? etc. ) - but I think that is solvable - and at least will be signifcant barrier to gate bad actors. This way simply PyPI would be outsourcing verification of such claims to the authorities.

Of course maybe I am biased - because ASF strength (besides community) is all about trademarks, ASF has the “Apache” trademark for software in multiple regions, and “Airflow” is registered trademark in US since June. So both “apache-” and “apache-airflow-” prefixes could be up for grabs for us. Maybe the criteria should be combined:

  • you have trademark
  • and you either pay or are reputable non-profit - in which case such thing will be treated as “donation” to the ASF and ASF would then list PyPi as “sponsor” or “partner” - similarly to what ASF does with Jetbrains, GitHub and a number of others.

Not judging what the final decision should be - but wanted to present our view as one of the potential important users of that feature.

4 Likes