But if the code is changing that much and it’s internal code then I don’t see how a lock file benefits you? My understanding of what you’re saying is you really just want a way to list things to install which requirements files already cover as well as PEP 621. But this PEP is not meant to be a general solution for listing anything you may want to install, but to install specific versions of things in a deterministic, secure fashion.
The lock file benefits me in keeping external dependencies locked. Each package in monorepo has it’s own list of dependencies. I need some way to produce a pinned/hashed requirements file that I can then install to keep external dependencies reproducible. If I have 3 internal packages today foo1, foo2, and foo3 there’s no direct way to produce a lock file of all of their dependencies without also including foo1/foo2/foo3 in the lock file. Installing things outside lock file isn’t an option since I lack any direct way to construct the lock file. Making a toy example let’s say I have these packages with these dependencies,
foo1 → X, Y, Z
foo2 → X, A
foo3 → Z
X → A, B
Y → None
Z → None
A → B
I would like to make a lock file off external packages of foo1/foo2/foo3. Something like,
I don’t see any way for any of the current tools to make that lock right now. I can make a lock that also includes foo1/foo2/foo3 with pip compile but then that file is unusable by pip due to the mix of editables/locks. So no editables in lock file is fine as long as there is a way to produce a lock file where resolver uses editables.
It is possible to work around by making a lock file with both hashes/editable, then making a script that removes editable, then installing that, and then installing editables afterwards. That’s a fairly messy solution and also means I can’t directly use normal pre-commit hooks like pip compile as the generated lock file they make needs post processing. Other workaround is building my own tool that concatenates setup.cfg/setup.py requirements and applies pip-compile to just that. Both of these workarounds boil down to make my own packaging mini-tool which I think most people that end up wanting editable + hashes will just give up and drop hashes.
edit: Part of the reason this issue is specific to monorepos with multiple packages is that for repository with exactly one package you can tell pip compile setup.py/pyproject.toml and it will produce a lock file of the dependencies of that package without including package itself. If you have multiple packages and you need a unified consistent environment then pip compile supports referring to each package including in a relative manner, but it’s not possible to do pip compile foo1/setup.py foo2/setup.py foo3/setup.py. So there’s a weird inconsistency here in that it’s easy to produce a lock file of dependencies for a package but harder to produce a lock of dependencies for multiple packages.