In fact this becomes a problem even for project maintainers as sometimes republishing an unmaintained broken package is extremely hard.
At least we need the ability for maintainers to flag a project as unmaintained or obsolete, without having to publish anything. The unmaintained state is not part of the metadata because is something that happens usually after the publication.
I have over 60 packages (hic) published over the years on pypi, and probably I could declare as unmaintained almost half of them.
This also have a lot of value for the users when they might be shopping on pypi for some goodies. Reality is that lots are rotten.
Flagging a project as unmaintained is really impossible. As stated earlier, this cannot be the responsibility of Pypi; Pypi cannot get into this kind of business of curating packages. The original maintainers of a package may also have passed away - or simply may not care. Adding this kind of flag to Pypi would not solve much, I think, and just create extra work for the Pypi maintainers.
I also don’t see that there is a real need here. Don’t clients realize that if a dependency is only supported up to say Python 3.1 (or so), they’d better start looking for an alternative (start maintaining their own fork of that package or contact the maintainers)? If a current package does not support (explicitly) at least Python 3.9, I would already not use it in new projects…
Clients need to do due diligence when first selecting a package - and need to continue doing this - I don’t see any way around this.
You mentioned that republishing a package can sometimes be hard. I cannot deny this (been there with awful legacy code), but it seems to me that that can only be caused by getting into too much technical debt - by neglecting that due diligence + update process too long.
Perhaps not, but PyPI could add a prominent warning on the project page when the project has not seen a release or update for, say, the last 3 years.
PyPI could also deemphasize such projects in its search results. In the example that prompted this discussion, Search results · PyPI should probably not show the parquet package at all, or perhaps show it grayed out in a dedicated area of the search results (not at the top of the results).
So, yeah, avoid curating packages, but still be a bit more helpful than expecting users to manually filter out stale projects by checking the last update/release data.
Yes, I agree. This could be done automatically - would be a pretty useful enhancement. The search could also be enhanced, as you suggested, or by giving more filter options (such as last release date after year).
On the other hand, I think, most users will already look at which Python versions are supported, when was the last release date, etc. Whenever I’m looking for sth new, I now also quickly take a look at the GitHub and see if there are open issues. If there are and they are more than 2 years old and without response, that’s a red flag for me. (I know, CPython itself has open issues that are almost 20 years old, but at least most (all?) of them do have some response )
The search could also be enhanced, as you suggested, or by giving more filter options (such as last release date after year).
Actually - that search option is already there (well, sth similar at least)! (Don’t know about the quality of the results however - it would be nice if there was a search only on package name + ‘last update’)
Flagging a project as unmaintained is really impossible. As stated
earlier, this cannot be the responsibility of Pypi; Pypi cannot
get into this kind of business of curating packages. The original
maintainers of a package may also have passed away - or simply may
not care. Adding this kind of flag to Pypi would not solve much, I
think, and just create extra work for the Pypi maintainers.
Please reread, Sorin requested “the ability for maintainers to flag
a project as unmaintained or obsolete, without having to publish
anything.” That’s not PyPI getting into any kind of business, it’s a
convenience feature for use by the original maintainers of a
As a package maintainer, if I want to mark my package as obsolete I
can do that with a new upload, but being able to indicate it without
uploading a new version of the package is currently not possible.
I understood this but didn’t reply to this part, or only partially. But my question here is what kind of use would this have? For who are you doing this? Yes, it could give a bit more clarity, sure, but if a package is already in use, and you (as client) don’t regularly try to rebuild with all your dependencies updated, then you will still discover too late that a package is no longer maintained…
I’m not arguing that Pypi shouldn’t add some mechanism or flag for maintainers to flag sth as obsolete, I just don’t see much use in that. (I think Pypi maintainers will also welcome any PRs, if somebody thinks otherwise and really sees this as urgent and wants to do sth about it…)
If a package has been marked as obsolete, pip could maybe refuse to install it unless a specific version is specified. That way, older projects that have the version pinned can still install it, but people won’t install it accidentally when they actually wanted to install a different package.
[Was this topic split off from another one? It can be pretty confusing when a “new” topic shows up which is missing some earlier context. It could be useful to add a post saying which thread it was split from.]