PyPI as a Project repository vs. Name registry (a.k.a. PyPI namesquatting, e.g. for Fedora packages)

As far as the original write-up goes, I can confirm that the problem I ran into with dnf was a C/C++ build system that directly created a system package for the system Python bindings, rather than emitting an sdist that could build fresh bindings for any Python installation.

Reworking the build system was more work than I was prepared to take on, so I instead reserved the name on PyPI and then allowed the use of system site packages in the project that needed those bindings.

The rpl package is waiting for being unblocked since October. Is there anything I can do to help unblock it?
As I feared, PyPI admin time is becoming a bottleneck now. I understand the reasons, but, wouldn’t it be better to have a process that doesn’t require admin access for the undisputed cases?

1 Like

The volume on this issue is pretty high. If you @-mention my GitHub username in the future these will get resolved faster.

1 Like

As I feared, it is now taking three months to unblock a package. Is there anything I can do to help PyPI admins speed this up?

2 Likes

Sorry, I missed the @-mention there somehow. I’ve resolved the issue.

1 Like

We can also make it possible for PyPI moderators to release these names, so it’s not blocked on administrators.

2 Likes

Yes that would be good, as long as @encukou investigates first to see if it’s legit the risk of releasing a package name to the wrong person should be minimal.

1 Like