Right, but even back in that Jurassic era you were still a Python core developer at the time (so you were, effectively, the “previous owner”)
A lot of these downloads happen because of installs that lack Tkinter.
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.
xdrlib onto GitHub (GitHub - da4089/py-xdrlib: Python module for XDR (IETF RFC1014 / RFC1832 / RFC4506) encoding and decoding) with the intention of taking over its maintenance. I’ve registered it as
py-xdrlib on PyPI because of the naming policy.
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?
I am perfectly ready to promise that if there is any interest of taking over this project, I will handle it over.
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 @mcepl wouldn’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…
python_requires had to be a
>= 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!).
Maybe not by the spec, but in practice it’s how it works
And that doesn’t include even shade of how much I hate upper-bounds as a distro Python packager.
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?