Would it be possible to update the aiohttp package on test.pypi?

[DevTGHa]

Hello, I am currently writing a package that has dependency on aiohttp.
It would be really helpful for me if aiohttp package can be updated on test.pypi server.
Thanks!

[webknjaz]

Could you explain your use case?

Caution

Normally, TestPyPI shouldn't be relied on — this is dangerous from the supply chain perspective.

I sometimes use it to test release automation in projects I maintain but it is important to understand that you should never trust projects that are uploaded on that index. You'll find that many transitive dependencies are either not there or might've been uploaded by arbitrary individuals and contain not what you expect.

---

I may decide to integrate it into our release pipeline but you still shouldn't rely on it except for one-time experimentation in well-isolated environments (not just a virtualenv but probably some hermetic container or even a VM).

[DevTGHa]

Certainly. The main reason is to have the our package as simple as possible.

I understand that it is vulnerable from the supply chain attack as the package can be changed anytime. However, for that reason, the official PyPi server doesn't allow to update the package under the same version, which make it a bit tricky to test the publishing the package part.

The other option that I considered was to configure the pyproject.toml to use the official pypi for the aiohttp package, but as I am making an opensource, I wanted to keep the pyproject.toml as simple as possible, which can be done if aiohttp>=3.13.2 is available on test.pypi.

If it helps, this is the package that I'm working on:
https://github.com/disguise-one/python-plugin

Thanks!

[webknjaz]

You don't need any runtime deps just for publishing to work.

[DevTGHa]

Certainly. It is just handy for us to test the published package in isolated environment with pip install -i https://test.pypi.org/simple/ designer-plugin, which is not possible due to outdated (?) package on test pypi server.

ERROR: Could not find a version that satisfies the requirement aiohttp>=3.13.2 (from designer-plugin) (from versions: none)
ERROR: No matching distribution found for aiohttp>=3.13.2

If you are reluctant to do this because of any reason, like security issue. I understand that :)
Thanks.

[webknjaz]

@DevTGHa what you describe is definitely insecure and you're going to open your test/dev envs to supply chain attacks. Instead, I'd recommend testing your project against published/trusted dists. You could, for example, use the wheel that you produce within the CI and run pip download ./path/to/your/project.whl to get a folder of wheels with all of your transitive deps from (regular) PyPI. Such folder is sometimes called a "wheelhouse", then you can point pip install to only look in that folder instead of online indices, meaning you'd be in control of what's install into your env, which is more secure. I encourage you to pair that with (pip-tools created) constraint files with dist hashes. Note that TestPyPI will likely go away at some point.

https://packaging.python.org/en/latest/guides/index-mirrors-and-caches/#caching-with-pip

---

TL;DR the reason I don't want to publish things to TestPyPI is (1) additional maintenance burden, which could be fine if automated like in other projects, but more importantly — (2) doing so hints people to (mis)use TestPyPI more in insecure ways and I (with my PyPA hat on) don't want to participate encouraging that. I know that certain installers (uv, I think) don't allow using multiple indices for dependency resolution while others (pip / pip-tools / etc.) can consult additional indices in addition to the main one.

---

On your metadata comment: from the core packaging metadata perspective it doesn't really matter if a project can't be resolved using a specific index for as long as you can satisfy the dependency in other way. Depending on the installer you're using, what I described above is a reasonable solution to have in place but you can also install a dependency from a different index using a separate command, before installing your wheel from other sourced. But still, I'd strongly recommend against installing things from TestPyPI, unless it's your own project and you're passing --no-deps to pip install so that your deptree isn't poisoned (poisoning will reach farther than just your venv since a bunch of things will often end up in the user-global cache, which endangers a lot more Python-facing envs on the same system).

[DevTGHa]

@webknjaz thanks a lot for your time to explain the very thorough detail.
I understand your point. Especially regarding the supply chain attack, I should've taken it more seriously.

I'm using uv for the package management, but there should be way to handle nicely with the uv as well. I'll research this bit further down. The wheelhouse approach does seem promising for our test pipeline tho. Appreciate the suggestion.