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 @mcepl 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 @mceplwouldn’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!).
Let’s not officially distribute software with known bugs, and no intent to let anyone fix them?
IMO it’s very different. By adopting something from Git history, you’re also taking the responsibility to maintain it – even if only for your own needs.
Yeah, okay, I’m remembering how I was persuaded around last time Let’s not worry about rehashing all the argument again.
So we don’t want to post the code anywhere ourselves, but can we at least take the standard names on PyPI and put up a link to the last committed version? Something so that people don’t have to dig all the way into these discussions to figure out what they should be doing, and something official looking enough that they won’t worry they’re breaking the rules by doing it.
Why does the name of the package matter? The package can be called whatever you want as long as you don’t change the module name. With the same module name it will still be a plug’n’play replacement of the old stdlib package afaik. So unless there’s something I don’t understand I would just name it something like nntplib-standalone and move on.
We’ve had a number of PyPI packages at the other end of the spectrum - versions of something that’s going into a future Python version, but not already released versions. Those have typically had “backport” in the name. From my limited perspective, those haven’t caused any major headaches (others may have a more negative view). Could we invent some similar tag that implies it’s not official, but will give people more time to move away? “-migration” or “-transitional” maybe?
Which is why changing a module from being a part of the standard library (and thus maintained by the PSF), to being on PyPI is such a big deal. PyPI is a much greater security risk than the standard library.
So maintaining the same name for the new, PyPI-hosted modules is exposing people to that additional risk, perhaps without their full knowledge.
I’m not sure what happened, as I can’t seem to find any public mention of it on this thread, anywhere in the PyPI GitHub org, or searching on Google, but after checking again, it seems that despite the multiple serious concerns expressed by the community, rather discouraging comments from the maintainer and a general consensus against it, expressed on the linked thread, that particular continuation of nntplib was in fact handed the original, official name on PyPI after all.
While the potential harms in this particular case is relatively limited, given it the module is for a relatively niche, obsolescent (though still in-use) protocol, other PEP 594 modules like cgi that see vastly more extent use are a whole different story. Therefore, and to be consistent and fair to other such maintainers like @_david who’ve been polite, diplomatic and understanding, we really should openly discuss and decide on a coherent policy in collaboration with the PyPI admins as soon as practical, before this becomes a larger problem.
Therefore, I’ve opened a new thread to discuss this:
Also,
Actually, it seems folks have had enough of a potential problem to open a detailed thread to consider doing something about it (which was prompted by the concerns of a number of Python core devs), as there is a current thread discussing exactly this.
However, the potential problem they pose is much less than in the current situation, as they are generally owned by the core devs and other known and trusted maintainers who developed them, whose work was already accepted into Python’s standard library, rather than by whatever third party happened to express interested in the package first. Furthermore, they will be shadowed in any future Python version that has them in the stdlib and thus serve no future ongoing purpose, whereas particularly if there is significant community interest, these names may remain relevant for many years to come.
It looks like the transfer was done prior to any of the comments on this thread (other than the OP and Praydun), the OP emailed admin@ and we released the name.
This leads into your next statement, but AFAIK there’s no real policy on stdlib names on PyPI. We added the automatic block years ago after a bunch of typosquats went up. I dont think we’ve thought about them much beyond that. Probably good to sort out a defined policy.
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.