# Pre-PEP: Add ability to install a package with reproducible dependencies **URL:** \ **Category:** Packaging\ **Created:** [July 20, 2025, 3:55pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497 "2025-07-20T15:55:45Z")\ **Posts on this page:** 13\ **Page:** 3
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [February 19, 2026, 7:23pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/43 "2026-02-19T19:23:16Z")
> [@Kound](#): > > Any suggestions on how to move forward? You could publish a package `-app` that has pinned dependencies, and then tell people to install that instead of `` if they intend to use it as an app? (And if that works well, then we could consider some metadata on `` that points to `-app` for any tooling that wants to reinterpret the context on behalf of the user.) ---
**Author:** ![Kound](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/kound/32/8195_2.png) [@Kound](https://discuss.python.org/u/Kound)\ **Post date:** [February 19, 2026, 8:18pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/44 "2026-02-19T20:18:13Z")
> [@steve.dower](#): > > You could publish a package `-app` that has pinned dependencies, and then tell people to install that instead of `` if they intend to use it as an app? How would I upload the additional `py.lock` for `-app` if PyPI / Warehouse does not support storing such a file? This approach works for the “embed `py.lock` inside the wheel” strategy, but not for the alternative approach of publishing a separate sidecar `*.whl.lock` file next to the original wheel — potentially also exposed via the [simple repository JSON project detail](https://packaging.python.org/en/latest/specifications/simple-repository-api/#simple-repository-json-project-detail), similar to `core-metadata`. To clarify my previous post: The idea is to publish a `py.lock` as a sidecar artifact at `{file_url}.lock`, analogous to `{file_url}.metadata` / `core-metadata`, so installers can optionally consume it. My question is mainly about process: how could such a feature be introduced without first having a full PEP? For example, would it be acceptable to add support in Warehouse for uploading a `py.lock` sidecar file associated with an existing wheel — without changing the Simple Repository API initially — so installers could attempt to fetch the lock file when explicitly instructed? This way, usage would remain completely optional and experimental. Would that be an acceptable way to go forward from here? ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 19, 2026, 8:36pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/45 "2026-02-19T20:36:46Z")
> [@Kound](#): > > My question is mainly about process: how could such a feature be introduced without first having a full PEP? I don’t think there is a way as once it’s on Warehouse people will come to rely on it. The PEP will have to demonstrate a desire/need for the feature to motivate it to be served from an index or shipped inside a wheel file. ---
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [February 19, 2026, 9:05pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/46 "2026-02-19T21:05:03Z")
You can have an entrypoint script for your app that verifies the parts needed for reproducibility prior to then launching the app. It’s inelegant, but it allows sidestepping the chicken-egg problem for the version that includes the lockfile in the wheel as a means of demonstrating demand prior to standardization allowing a more elegant version. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [February 19, 2026, 9:05pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/47 "2026-02-19T21:05:32Z")
> [@Kound](#): > > How would I upload the additional `py.lock` for `-app` if PyPI / Warehouse does not support storing such a file? It seems like you’re fixated on a particular solution, rather than thinking about just solving your problem. Wheels/sdists have dependency metadata. _By convention_, that is unpinned in libraries, but it’s entirely possible to just pin it and publish a regular wheel (either metadata-only, or perhaps you put the CLI in a separate package). When someone installs it, the other packages willmatch exactly what it requires, reproducing the dependencies. If you’re insistent on creating something different, then you really need to set it up and demonstrate it, before arguing that it should be merged into the existing tool (where it becomes incredibly difficult to change or remove, as Brett says). You don’t need a PEP to set up your own index, or to encourage tools to support your index (though some may want it to be a community standard before they’ll support it - that just means you haven’t encouraged them enough 😉 ). Or you can use an approach that already exists, already works, doesn’t require anyone to change anything more drastic than the one install command that currently doesn’t do the thing they want it to do. I’m not forcing anything, I’m just ignoring your solution and offering you a much easier way to solve your problem. ---
**Author:** ![dstufft](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dstufft/32/23_2.png) [@dstufft](https://discuss.python.org/u/dstufft)\ **Post date:** [February 20, 2026, 2:17am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/48 "2026-02-20T02:17:16Z")
A possibly interesting point of prior art here, is that `cargo install` has a `--locked` flag that will use the `Cargo.lock` from the the thing that is being installed instead of using the unlocked dependencies in `Cargo.toml`. That ecosystem is different from ours though. IIRC `cargo install` can only install a single “thing”, and it’s use case is pretty much entirely installing a CLI into the system, and it’s not part of the regular day to day functionality of writing a Rust project and adding/removing dependencies. `cargo install` is closer in spirit to something like `pipx install`. In python `pip/uv/etc install` typically accepts multiple things, and it more closely related to something like `cargo add` than `cargo install`. ---
**Author:** ![edgarrmondragon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/edgarrmondragon/32/14205_2.png) [@edgarrmondragon](https://discuss.python.org/u/edgarrmondragon)\ **Post date:** [February 20, 2026, 2:29am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/49 "2026-02-20T02:29:47Z")
> [@Kound](#): > > How would I upload the additional `py.lock` for `-app` if PyPI / Warehouse does not support storing such a file? Instead of doing that, you have to _somehow_ build a package with pinned dependencies in its METADATA, there are many ways of doing that. Not exhaustively: - setup.py where the `install_requires=` is generated from the contents of a requirements.txt file with pinned dependencies. That file can be generated with `pip-compile` or `uv pip compile`, for example. - [GitHub - repo-helper/hatch-requirements-txt: Hatchling plugin to read project dependencies from requirements.txt](https://github.com/repo-helper/hatch-requirements-txt/), with a similar step for generating requirements.txt. - [GitHub - edgarrmondragon/hatch-pinned-extra: Hatch plugin that adds a packaging extra to the wheel metadata with pinned dependencies from uv.lock](https://github.com/edgarrmondragon/hatch-pinned-extra/) to inject pinned dependencies from `uv.lock` (DISCLAIMER: I’m the author) ---
**Author:** ![ctrueden](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ctrueden/32/34916_2.png) [@ctrueden](https://discuss.python.org/u/ctrueden)\ **Post date:** [March 27, 2026, 6:20pm UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/50 "2026-03-27T18:20:12Z")
Coming from the Java world, where dependency resolution (as performed by Maven) is both reproducible and composable, I often feel frustrated that many other dependency management ecosystems lack both of these features simultaneously. The tradeoff is typically framed as reproducibility (lockfiles, “for applications”) _versus_ composability (loose versioning, “for libraries”), but it does not have to be this way. I finally got around to writing a blog post about it: > **[Python Dependency Managementis Missing a Piece](https://ctrue.name/2026/03/27/python-dep-mgmt-missing-piece.html)** The Python community is being continuously hurt by the tooling’s inability to deliver reproducible and composable environments intuitively by default. I hope threads like this one can lead to some consensus on how to fill this gap. ---
**Author:** ![Spaceman](https://avatars.discourse-cdn.com/v4/letter/s/a5b964/32.png) [@Spaceman](https://discuss.python.org/u/Spaceman)\ **Post date:** [March 30, 2026, 5:23am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/51 "2026-03-30T05:23:39Z")
I publish a few applications (and libraries) on pypi and I can’t count the hours I’ve been wrestling and analyzing issues with dependencies. Some say the real reason docker has been invented was because python packaging is such a mess and every time I stumble on a dependency issue I (again) think of yanking my applications from pypi and publish docker images only. Maybe I’m not smart enough or don’t understand everything correctly but it would be really nice if there was a straightforward method of pinning dependencies (and sub-dependencies) which result in reproducible installations per python version. I also teach python and and all the questions I get asked after my courses are (exclusively) package installation related, e.g. dependencies that not longer work because of newer sub-dependencies, python version mismatch, sometimes missing build dependencies. > [@steve.dower](#): > > Wheels/sdists have dependency metadata. _By convention_, that is unpinned in libraries, but it’s entirely possible to just pin it and publish a regular wheel (either metadata-only, or perhaps you put the CLI in a separate package). When someone installs it, the other packages willmatch exactly what it requires, reproducing the dependencies. In theory you are right - it’s entirely possible to write a dependency file which pins all dependencies and sub dependencies. But let’s say I have a dependency A, which has version A1 for python 3.12, A2 for python 3.13 and A3 for python 3.14. It also has a sub-dependency version SA1 for python 3.12, SA2 for python 3.13 and SA3 for python3.14. I’m also supporting 3.11 and 3.10 because there is no real reason not to but on my machine I’m developing with 3.12. There is no easy way to generate an exhaustive list of pinned dependencies across python versions AND supply them as package metadata in a standardized way so they are properly used when a user installs my application. And even if I managed to do it (manually) once, updating these dependencies is again very difficult. It’s very confusing to me that I need seven additional tools and three custom scripts for this simple use case (numbers made up). All I want is that the initial installation is done with the dependencies I tested. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 30, 2026, 7:52am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/52 "2026-03-30T07:52:52Z")
You should publish a lockfile. Unfortunately, the ecosystem support for lockfiles is still developing, so there are a bunch of problems with that recommendation right now, but we are getting there. The problem is “just” implementation, though, not lack of a solution. Python packaging is much stronger around publishing libraries rather than applications. That’s a known weakness, unfortunately. But we _are_ working on it. ---
**Author:** ![Spaceman](https://avatars.discourse-cdn.com/v4/letter/s/a5b964/32.png) [@Spaceman](https://discuss.python.org/u/Spaceman)\ **Post date:** [March 30, 2026, 8:21am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/53 "2026-03-30T08:21:28Z")
> [@pf\_moore](#): > > You should publish a lockfile. Unfortunately, the ecosystem support for lockfiles is still developing, so there are a bunch of problems with that recommendation right now, but we are getting there. The problem is “just” implementation, though, not lack of a solution. I tried that, but it’s impossible to install e.g. from a uv/poetry lock file with pip. It’s also unclear to me how the user would use the data from the lock file for installation. Where could I read up on this? > [@pf\_moore](#): > > But we _are_ working on it. I’m aware and that’s awesome! I just wanted to give additional perspective on the pain points and point out that from my perspective packaging seems to be one of the bigger issues - especially for newcomers. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [March 30, 2026, 9:40am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/54 "2026-03-30T09:40:34Z")
> [@Spaceman](#): > > I tried that, but it’s impossible to install e.g. from a uv/poetry lock file with pip. I don’t believe uv or Poetry use standard lockfiles as their native format. You’d probably have to export to the standard format if you wanted a tool-independent solution. I don’t know if they have plans to switch to standard lockfiles as their native format. As I said, it’s early days yet. > [@Spaceman](#): > > It’s also unclear to me how the user would use the data from the lock file for installation. On the [pip tracker](https://github.com/pypa/pip/issues/13334), we’re talking about a `pip sync` command, or maybe `pip install -r pylock.toml`. But it’s still very much at the “work out what the UI would look like” stage. And I have no idea what commands uv or Poetry would have to install from a standard lockfile - you’d have to ask them. > [@Spaceman](#): > > Where could I read up on this? The definitive information is [the lockfile spec](https://packaging.python.org/en/latest/specifications/pylock-toml/) but it’s intentionally low on UI details, because the UI is up to individual tools to decide, and most tools are (I believe) still working on that. There’s also a question around whether PyPI would allow publishing lockfiles, which is again still at the “thinking about it” stage, I believe. > [@Spaceman](#): > > I just wanted to give additional perspective on the pain points and point out that from my perspective packaging seems to be one of the bigger issues - especially for newcomers. Understood, and thanks for that 🙂 Progress _is_ slow, but it’s happening - lockfiles took many years to standardise, and will likely take a few more years to implement, but they are a key piece of functionality, and should make things a lot better for application distribution (among other things). ---
**Author:** ![aragilar](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@aragilar](https://discuss.python.org/u/aragilar)\ **Post date:** [March 30, 2026, 9:56am UTC](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497/55 "2026-03-30T09:56:45Z")
It’s interesting that the three ecosystems you mention as scoring well (JVM, .NET, go) all struggle to integrate with other ecosystems, whereas the other ecosystems have traditionally been good at integration (and conda-forge’s main purpose is multi-ecosystem integration). [Previous page](https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497.md?page=2)