I must say, this experience is increasingly leaving me with unease. There is a tendency to assume bad faith on my part in the worst case or as a minimal avatar of corporate interest in the best case.
Here is what the enumeration pulls from:
-
This is cool. Actually we had a very relevant discussion today about a potential confusion and new provider created by someone […] would be nice if we could make it a convention and have a way to enforce the “root” namespace to only be used by Apache Airflow team. This is also the “expectation” of the ASF - naming convention of packages is part of “branding” expectations from project - and currently with PyPI is not enforceable - with that change however it could be.
-
[…] we’d need to ensure that people can’t squat these names for security reasons. As opposed to other Python packages, people will just try to install the type stubs without previously checking them, and they should be able to. But without namespacing this would open a wide door to attackers. So for us, namespacing is essential.
-
I think this is really interesting, and a good idea. […] there may be a slight preference in parts of in our community for npm-style, largely because our projects often straddle npm and PyPI […] But I definitely see the strong backward-compatibility arguments of the prefix approach. […] Any transition will be tricky for us because the existing widespread use of prefixes is very much used by both official projects and community plugin packages, alike. This has been a communication issue, in that it is unclear from package names alone, what projects are ‘official’. […] The current proposal would not change that, but it would at least stop the unofficial population of the plugin namespace from growing.
There was a misunderstanding which caused the following thinking that they couldn’t benefit i.e. open grants didn’t allow uploads from others:
I don’t think we would pick moving to a new only-official prefix unless it was
@npm-style. I’m not 100% sure we would do that, given the user impact. […] I had definitely misunderstood the public/private namespace distinction, since the definitions in the PEP are not what I expected those words to mean (the “open/closed” labels some folks have mentioned feel more intuitive to me). I believe I understand now, thank you. -
I’ll speak officially […] We would likely want to take full ownership of the
azure-namespace, and suggest that third-parties use an-azuresuffix instead. -
I’ll also speak officially on behalf of my employer. We would pay to reserve
datadog
I said:
That’s a great idea actually, I could add an explicit exception that reviewers could grant community projects a private namespace at their discretion.
This was not some deal specifically for them to make them happy but rather for “community projects” as a concept. In any case, this part is gone in the latest policy update.