pypi
Ability to mark a version of a package as deprecated or unsupported
Then warehouse can serve that info back when pip looks up a package, and pip can display a warning.
This allows maintainers to inform users that theyr'e using an out of date version, without needing them to modify the source of the old package.
I'm guessing pip would display this warning when you do pip list --outdated and it's a stronger warning than the outdated warning?
Would it also not allow you to do a pip install of that deprecated versions without some kind of force?
I think just a warning on pip install to start.
On Sat Dec 20 2014 at 12:53:12 PM Marc Abramowitz [email protected] wrote:
I'm guessing pip would display this warning when you do pip list --outdated and it's a stronger warning than the outdated warning?
Would it also not allow you to do a pip install of that deprecated versions without some kind of force?
— Reply to this email directly or view it on GitHub https://github.com/pypa/warehouse/issues/345#issuecomment-67749289.
This came up during a Pycon dinner conversation. IWBNI the admins could similarly mark a package. We were discussion the still active use of oauth despite the fact that it's been unmaintained (with no new uploads) upstream since 2009, isn't py3 compatible, there are better replacements (albeit with different APIs) on PyPI, and yet oauth still comes up as the top search hit. We don't want people using the package any more, but we also don't want to break existing usages. I'd like to see the package deprecated with a pip warning on install, and also down-rank the package in PyPI searches.
So given a mechanism like described in this ticket, it would be technically possible for the PyPI admins to do that. The bigger question would be whether or not we'd want to declare something unmaintained by fiat. Having the admins declare something unmaintained has a decent chance of blowing up if we accidentally mark something as unmaintained when it's really not unmaintained, it's just "finished" (for some value of finished).
That doesn't of course mean we can't do it, but that the biggest barrier would be determining a policy for when we consider it something that's OK to do.
/cc @r1chardj0n3s
Sure, you'd want to be careful, but no uploads in the last 6 years is a pretty good sign a package is abandoned.
I would only do such a thing if I could get the approval of the owner of the listing.
On Sat, 11 Apr 2015 07:43 Barry Warsaw [email protected] wrote:
Sure, you'd want to be careful, but no uploads in the last 6 years is a pretty good sign a package is abandoned. Maybe you could even automate some of the criteria (no recent uploads for some $value of recent, etc.)
— Reply to this email directly or view it on GitHub https://github.com/pypa/warehouse/issues/345#issuecomment-91831525.
In addition to emitting a warning through pip, I'd make sure the Warehouse shows a big banner with a deprecation notice and in that banner link to a potential successor module (in the way PEP-437 intended the obsoleted_by keyword). As a first measure, I'd add an option to the package preferences on Warehouse to name a successor package (and if there is none, e.g. because the package is no longer developed, just show a generic deprecation message on Warehous).
Maybe you could even automate some of the criteria (no recent uploads for some $value of recent, etc.)
Instead of showing a big warning in this situation, I'd just add a small notice to the download section of the package on Warehouse indicating that the package hasn't been updated in a while. Packages with the "Mature" specifier could be excluded from this automatic notice. Packages with pre-release specifiers could have a shorter notice period than "Stable" packages.
What about a classifier, perhaps a "Development Status" level, that developers could use when they consider their package "finished"? Packages that have that won't be marked as "unsupported".
What about a classifier, perhaps a "Development Status" level, that developers could use when they consider their package "finished"? Packages that have that won't be marked as "unsupported".
That's what Development Status :: 6 - Mature and Development Status :: 7 - Inactive are for, I suppose.
Thanks for the issue and discussion, and sorry for the slow response!
The folks working on Warehouse have gotten funding to concentrate on improving and deploying Warehouse, and have kicked off work towards our development roadmap -- the most urgent task is to improve Warehouse to the point where we can redirect pypi.python.org to pypi.org so the site is more sustainable and reliable.
In our meeting today we decided that, since this feature isn't something that the legacy site has, it belongs in a future milestone.
I personally would love this feature, and though it's not as urgent for this team to work on during its grant-funded period, I would appreciate volunteers working on this issue, especially on the policy/PEP level.
Thanks and sorry again for the wait.
Now that PEP 592 is accepted and #5837 is resolved, I hope you will consider looking at the yanking feature and see whether it suits your needs? Yanking is one way to mark a package as deprecated but it may not suit all your use cases.
NPM allows the package owners/authors to declare the package as deprecated, adding a very visible message on the package's page about it.
See https://www.npmjs.com/package/iltorb for example.
Here's a proposal: Add a "deprecate package and yank all releases" button in the Manage Project page.
It'll let the owner provide a message that's presented prominently on the package page and would, as the name suggests, also yank all the existing releases. New releases cannot be made for a deprecated package. It'll be possible for an owner to un-deprecate a package, but this operation would not un-yank the past releases.
NPM allows the package owners/authors to declare the package as deprecated, adding a very visible message on the package's page about it.
I was looking at NPM's deprecation recently and wanted to clarify that NPM deprecation is release-specific. When you use npm deprecate PACKAGE_NAME without a version range, it's actually marking all the versions as deprecated. If you visit an NPM package page and see the deprecation message, it really only signifies that the latest version was deprecated (altho other versions could be too).
Nobody can expect that a dead/unmaintained project to be able to make a new release just to declare itself as dead. We really need an wheelhouse API option to declare packages as obsolete, just we have the ability to yank or remove stuff.
👋 folks, chiming in here as a maintainer for a library distributed via PyPi. Adding the ability to yank a released version, or having some kind of functionality that clearly signals to a consumer of a library that they need to update to a specific version, would be incredibly beneficial to folks who upload and maintain packages. I genuinely hope that this is a feature that can get picked up soon!
Triage: PyPI now supports an "archived" status, which project owners can use to declare that a project is not receiving any additional releases or maintenance: https://github.com/pypi/warehouse/pull/17005
I believe that addresses the first aspect of this, although the "archived" status is not (yet) exposed via any of the Simple Index/JSON APIs.
Triage: PEP 792 has been written, approved, and finalized and now implemented on PyPI:
https://blog.pypi.org/posts/2025-08-14-project-status-markers/
This exposes the "archived" status (among others) via the standard index APIs.
Given that, I think this is OK to close -- there's also a "deprecated" status in the PEP that PyPI hasn't implemented yet, but the core machinery is in place (and this issue asks for an "unsupported" marker, which "archived" is.)