HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
pypi
warehouse
Python2016–2026
pypi / warehouse

warehouse

The Python Package Index

30Distinct people
45Mentions
0Explicit recommenders
4.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Python Package Index

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year45 dated mentions

Observed mentions: 2016-05-16 11:04:07 UTC to 2026-03-27 21:57:46 UTC.

02468102016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 2 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC220
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC725
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC909
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC404
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Warehouse Warehouse is the software that powers PyPI. See our documentation and architectural overview. Getting Started You can run Warehouse locally in a development environment using docker. See Getting started documentation for instructions on how to set it up. The canonical deployment of Warehouse is in production at pypi.org. Discussion You can find help or get involved on: Github issue tracker for reporting issues IRC: on Libera, channel #pypa for general packaging discussion and user support, and #pypa-dev for discussions about development of packaging tools The PyPA Discord for live discussions The Packaging category on Discourse for discussing new ideas and community initiatives Testing Read the running tests and linters section of our documentation to learn how to test your code. Code of Conduct Everyone interacting in the Warehouse project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the PSF Code of Conduct.
Read the full README on GitHub

What Hacker News says

45 sources
> I think the python community, and really all package managers, need to promote standard cache servers as first class citizens as a broader solution to supply chain issues. What I want is a server that presents pypi with safeguards I choose. For instance, add packages to the local index that are no less than xxx days old (this uv feature), but also freeze that unless an update is requested or required by a security concern, scan security blacklists to remove/block packages and versions that have been found to have issues. Update the cache to allow a specific version bump. That kind of thing. FWIW, https://pypi.org/project/bandersnatch/ is the standard tool for setting up a PyPI mirror, and https://github.com/pypi/warehouse is the codebase for PyPI itself (including the actual website, account management etc.). If "my own curated pypi" ex
Read the rest
tends as far as a whitelist of build artifacts, you can just make a local "wheelhouse" directory of those, and pass `--no-index` and `--find-links /path/to/wheelhouse` in your `pip install` commands (I'm sure uv has something analogous).
In Telnyx package compromised on PyPI
I'm assuming by pip you mean pypi (the package registry) - I think you're making the mistake of thinking it has a lot more resources than it does, because of how much it punches above its weight. Pypi is powered by warehouse which has around 3 developers maintaining it[0]. They're doing an awesome job, but the funding and resource available to them are probably substantially less than Astral could have with a paid offering. [0] https://github.com/pypi/warehouse/graphs/contributors
In PYX: The next step in Python packaging
> I think this is a design issue with PyPI though. It really should have some kind of index which goes from module names to packages which provide that module. (Maybe it already does but I don't know about it?) PyPI never really saw much "design" (although there is a GitHub project for the site: https://github.com/pypi/warehouse/ as well as for a mirror client: https://github.com/pypa/bandersnatch). But an established principle now is that anyone can upload a distribution with whatever name they want — first come, first serve by default. Further, nobody has to worry about what anyone else's existing software is in order to do this. Although there are restrictions to avoid typo-squatting or other social engineering attempts (and in the modern era, names of standard library modules are automatically blacklisted). > Of course, that doesn't h
Read the rest
elp if multiple packages provide the same module; but then if there was a process to reserve a module name – either one which no package is currently using, or if it is currently used only by a single package, give the owner of that package ownership of the module – and then the module name owner can bless a single package as the primary package for that module name. These kinds of conflicts are actually by design. You're supposed to be able to have competing implementations of the same API. > Obviously it shouldn't do this by default... maybe something like "from __future__ import auto_install" to enable it. The language is not realistically going to change purely to support packaging. The time to propose this was in 2006. (Did you know pip was first released before Python 3.0?) > but maybe Python will eventually get there. That would require the relevant people to agree that with heading in that direction. IMX, they have many reasons they don't want to. Anyway, this isn't the place to pitch such ideas. It would be better to try the Ideas and/or Packaging forums on https://discuss.python.org — but be prepared for them to tell you the same things.
In Uv: Running a script with dependencies
Excellent idea, and something I tried a little while back. The `pytest-postgresql` plugin used has the ability to do this natively, but when we tried it out we found that we had other issues with developing on a Linux machine. Attempt: https://github.com/pypi/warehouse/pull/15365 Revert: https://github.com/pypi/warehouse/pull/15444 If you've got experience with making this kind of thing work on Linux development machines, it'd be great to have some help getting that back.
In Making PyPI's test suite 81% faster
Well, I think there should be broader discussion of this inadequacy. "Implement "hook" support for package signature verification." (2013) https://github.com/pypi/warehouse/issues/1638#issuecomment-2... "GPG signing - how does that really work with PyPI?" https://github.com/pypa/twine/issues/157#issuecomment-101460... "Better integration with conda/conda-forge for building packages" https://github.com/pyodide/pyodide/issues/795#issuecomment-1... Conda now has their own package cryptographic signature software supply chain security control control. Unfortunately, conda's isn't yet W3D DIDs with Verifiable Credentials and sigstore either. Also, [CycloneDX] SBOMs don't have any package archive or package file signatures; so when you try to audit what software you have on all the containers on your infrastructure there's no way to check the
Read the rest
cryptographic signatures of the package authors and maintainers against what's installed on disk. docker help sbom # check_signatures python conda zipapps apt/dnf/brew/chocolatey_nuget git /usr/local And without clients signing before uploading, we can only verify Data Integrity (1) at the package archive level; (2) with pypi's package signature key.
In Removing PGP from PyPI
This is misleading: the trusted publisher is GitHub's OIDC IdP, which happens to be the single most common publishing source for PyPI (as well as the first IdP to give us all the features we needed). It has absolutely nothing to do with Microsoft; I don't think Microsoft (as a discrete corporate entity) was even aware of the work. The feature was intentionally built to be extensible and to support additional publishers. I know this because I'm the one who made it extensible, and who's working on supporting them[1][2]. [1]: https://github.com/pypi/warehouse/issues/13551 [2]: https://github.com/pypi/warehouse/issues/13575
In PyPI new user and new project registrations temporarily suspended
> There needs to be some extra step, be it a fee, identity confirmation, manual moderation/approval, or something else. I'm sure the PyPA devs/maintainers have ideas. When I was younger, I always thought computing was so incredibly cool, because me, just some blind kid in Florida, could contribute and make things and share things and just ...participate. I would talk to friends trying to go in to other careers, and excitedly talk about what I was working on and be curious why they never did anything related to what they wanted to do when they grew up. Now, I understand how this comes about, bit by bit, with the best of intentions. And I hate it. Please, just no. If you want to set up a corporate only, super-sekret clubhouse of a PyPi that only the authorized developers can push to, well, the source code for PyPi is right here[0]! And her
Read the rest
e's Stripe[1]! But please don't break even more of the open, free Internet that I grew up with, I'm pleading with you. [0]: https://github.com/pypi/warehouse [1]: https://dashboard.stripe.com/register
In PyPI new user and new project registrations temporarily suspended
Your cynicism isn't warranted: we've made significant improvements to PyPI over the last 4 years[1][2], and I'm currently working on additional features that will make secure publishing to PyPI easier[3]. We're also working on a codesigning implementation for PyPI, based on Sigstore[4]. Security needs to be evidence and outcome-driven, first and foremost. That takes a while, but improved outcomes make it worth it. [1]: https://pyfound.blogspot.com/2019/06/pypi-now-supports-two-f... [2]: https://pythoninsider.blogspot.com/2019/07/pypi-now-supports... [3]: https://github.com/pypi/warehouse/issues/12465 [4]: https://www.sigstore.dev/
In Aggressive Attack on PyPI Attempting to Deliver Rust Executable

Showing the 15 most recent of 45 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.