When I try to upload the package to PyPI, it gets rejected because it is using name of from the standard library. Would it be possible to get here exception, because I think it would be much easier for everybody involved if the name has not changed.
Consider emailing admin@pypi.org – they have the ability to unblock packages like this, to allow you to publish it.
Out of the box, the standard library package names are blocked from permitting uploads (eg: coz newcomers would try things like pip install random etc).
For some reason, though, there is a turtle package on PyPI and it has caused headaches for a lot of people (it’s completely unrelated to Tkinter or turtle graphics, and has been unmaintained for many years). I guess I should email them about this, but I am wondering how it happened, if what you say is true.
One concern, though, is that since it is a “special” name of a stdlib package that is EoL from its previous owners, awarding the canonical name to someone does put the PyPI maintainers in the position of de-facto having to pick who gets to be the maintainer of the module going forward, which is a lot of power and responsibility to put in any one person’s hands. This is particularly the case for a project owned by a single maintainer (hosted on a site that, AFAIK and I may be wrong, doesn’t really have a mechanism to easily allow otherwise, and somewhat lacking in modern collaboration mechanisms), as opposed to a community project founded by a number of interested stakeholders.
Maybe PyPI itself could PEP 541 request it and remove it (since the name should revert to PyPI’s ownership, being on the blocklist)? It only had two releases, 0.0.1 and 0.0.2 both on the same day in 2009, and the homepage link is blocked on my browser as a malware site. Checking it on PyPIstats, it has 40k downloads per month, but essentially 100% of those are likely by mistake as overwhelming majority (all but a few dozen per day) are for Python 3, whereas the package was released just after Python 3.0 came out (and before Python 3.1 and 2.7, even), and the setup.py contains Python 2-only syntax. Furthermore, AFAIK it won’t actually work anyway because the stdlib module will shadow it.
I know this was back in the Jurassic era and much has clearly changed since then, but I created the bsddb185 project on PyPI when that module was dropped in 2.7.
hosted on a site that, AFAIK and I may be wrong, doesn’t really have a mechanism to easily allow otherwise, and somewhat lacking in modern collaboration mechanisms
That’s rather nasty slander … I believe that email is much better collaborating mechanism than dealing with a silly website.
And of course, anybody willing to share rights to that project is more than welcome.
Err, I’m not sure its fair (and a bit uncalled for) to characterize the statement:
…as “rather nasty slander”. It just was just my heavily qualified personal impressions of the platform based on my examination of the website and the descriptions in its own documentation, issue tracker and communication channels, which I explicitly prefaced with multiple disclaimers as to my uncertainty regarding it and placed in an ancillary parenthetical sidenote.
I would appreciate if you could keep things civil and respectful in the future, thanks. And if anything, this amplifies rather than assuages my general concerns about PyPI transferring ownership of a privileged stdlib name to a specific individual in cases such as this.
You’re of course welcome to your opinion on that, one that I imagine its likely that anyone else still interested in maintaining a NNTP library will probably share—in that respect, Sourcehut is perhaps a particularly apt choice. However, I was more referring to general platform limitations rather than the interaction method, most specifically in terms of sharing project ownership and reducing bus factor (which itself was secondary to the broader question as to whether PyPI should be transferring privileged stdlib module names to individual owners at all).
That’s great to hear, thanks. How would that work on Sourcehut, though, exactly? As expressed above, my limited understanding based on e.g. this discussion and this issue is that shared project ownership is not (yet) possible on Sourcehut, though it appears to be under development.
With enough good will anything is possible. After all, that issue is just about having multiple people who can run git push, and that’s after all that real collaboration happens on the email list really happens.
I’m not sure it makes sense for minor modules like these to inherit the namespace of the stdlib packages. Who’s to say that my stewardship is as secure, long-lived, etc, as the PSF? Forcing some manual consideration into the adoption process seems reasonable.
It’d be nice to have a textual redirection entry on PyPI though?
The issue I considered is that the PSF is a trusted entity with thoughtful processes and individuals with social status to at risk if they do the wrong thing.
If module namespaces, formerly owned by the PSF, are handed out to “random” individuals, that’s a backdoor that would potentially allow a bad actor access to a lot of installations. Which is not to say that anyone is a bad actor, but … there’s no way to know we’re not.
That, and also even if someone themselves is by no means a bad actor (which, FWIW, I have no reason to believe @anon50483532 is), their account could get compromised by one, or (perhaps more likely) they could in good faith end up handing the project over to someone else who later turns out to be one. Looking at the volume of requests the unrelated turtle module gets, that’s a non-trivial number of users that could be immediately compromised with remote code execution (since an attacker can easily run arbitrary code at install time) should the account owning the nearly 15 year old abandoned project get compromised at any point (or any of their other accounts get compromised which allowed their PyPI one to be).
Also, equally, I have no reason to believe @anon50483532wouldn’t hand over the project if possible, but what they get hit by a (proverbial or actual) bus? Then its down to waiting in the long PEP 541 queue again, at best…and how to know if that person is trusthworthy? Or what if multiple users are requesting the same name? It gets rather thorny.
Which is the argument going exactly the same against ALL modules on PyPI. How can you use in your project which you sell to your customers libraries from unknown developers with unknown agendas?
Maybe the only balanced answer here is to freeze the modules on PyPI under the “standard” name, and encourage people to fork and maintain and publish independently under a new name if they want to.
It’s basically the same as leaving the standard name inaccessible and pointing people to the last Git commit containing the file (as most are single files). But since we’ll have done something it’ll reduce the number of people asking us to do something.
On some level, we do want people to stop using these libraries If everyone wanted them to be used, they’d have maintainers working on them and they wouldn’t be rotting away in our repository. But at least if the version number is set at 3.11 on PyPI and never changes again it won’t be such a surprise that they’re rotting away.
If we did that (I think it’s a reasonable idea, TBH) would we set the published packages to have python_requires <= 3.11, so that the published versions wouldn’t install in later Pythons? Or would we leave that out, so that people can install the old rotting versions in newer Pythons (with clear documentation that there’s no support for using the module in newer versions)? Both approaches have their advantages, IMO…
I thought python_requires had to be a > or >= check? But I’d be inclined to either prevent installing them in versions where they were in the stdlib (so python_requires >= 3.12) or leave it out and let people take their own risks.
[Later] Actually, people would need environment markers to depend on them anyway, so there’s no real benefit in restricting the install versions. Just document “hey, if you install these downlevel you might make things worse, so specify in your install_requires as …”
But preventing installation on versions where it’s in the stdlib seems like a good idea (better than my suggestion of only allowing installation on such versions!).
