Market research
This post is only about dependency management, not package management, not build backends.
You know about these:
-
uv
-
poetry
-
pipenv
You are probably not familiar with:
-
pip-compile-multi
(toposort, pip-tools)
You are defintely unfamiliar with:
-
wreck
(pip-tools, pip-requirements-parser)
pip-compile-multi creates lock files. Has no concept of unlock files.
wreck produces both lock and unlock files. venv aware.
Both sync dependencies across requirement files
Both act only upon requirements files, not venv(s)
Up to speed with wreck
You are familiar with .in and .txt requirements files.
.txt is split out into .lock and .unlock. The later is for packages which are not apps.
Create .in files that are interlinked with -r and -c. No editable builds. No urls.
(If this is a deal breaker feel free to submit a PR)
pins files
pins-*.in are for common constraints. The huge advantage here is to document why?
Without the documentation even the devs has no idea whether or not the constraint is still required.
pins-*.in file are split up to tackle one issue. The beauty is the issue must be documented with enough details to bring yourself up to speed.
Explain the origin of the issue in terms a 6 year old can understand.
Configuration
python -m pip install wreck
This is logging-strict pyproject.toml
[tool.wreck]
create_pins_unlock = false
[[tool.wreck.venvs]]
venv_base_path = '.venv'
reqs = [
'requirements/dev',
'requirements/kit',
'requirements/pip',
'requirements/pip-tools',
'requirements/prod',
'requirements/manage',
'requirements/mypy',
'requirements/tox',
]
[[tool.wreck.venvs]]
venv_base_path = '.doc/.venv'
reqs = [
'docs/requirements',
]
dynamic = [
"optional-dependencies",
"dependencies",
"version",
]
[tool.setuptools.dynamic]
dependencies = { file = ["requirements/prod.unlock"] }
optional-dependencies.pip = { file = ["requirements/pip.lock"] }
optional-dependencies.pip_tools = { file = ["requirements/pip-tools.lock"] }
optional-dependencies.dev = { file = ["requirements/dev.lock"] }
optional-dependencies.manage = { file = ["requirements/manage.lock"] }
optional-dependencies.docs = { file = ["docs/requirements.lock"] }
version = {attr = "logging_strict._version.__version__"}
Look how short and simple that is.
The only thing you have to unlearn is being so timid.
More venvs. More constraints and requirements complexity.
Do it
mkdir -p .venv || :;
pyenv version > .venv/python-version
python -m venv .venv
mkdir -p .doc || :;
echo "3.10.14" > .doc/python-version
cd .doc && python -m venv .venv; cd - &>/dev/null
. .venv/bin/activate
# python -m pip install wreck
reqs fix --venv-relpath='.venv'
There will be no avoidable resolution conflicts.
Preferable to do this within tox-reqs.ini
Details
TOML file format expects paths to be single quoted. The paths are relative without the last file suffix.
If pyproject.toml not in the cwd, --path='path to pyproject.toml'
create_pins_unlock = false tells wreck to not produce .unlock files for pins-*.in files.
DANGER
This is not for a faint of heart. If you can avoid it. This is for the folks who often say, Oh really, hold my beer!
For pins that span venv, add the file suffix .shared
e.g. pins-typing.shared.in
wreck deals with one venv at a time. Files that span venv have to be dealt with manually and carefully.
Issues
-
no support for editable builds
-
no url support
-
no hashs
-
your eyes will tire and brains will splatter on the wall, from all the eye rolling after sifting thru endless posts on uv and poetry and none about pip-compile-multi or wreck
-
Some folks love having all dependency managed within pyproject.toml These folks are deranged and its impossible to convince them otherwise. pyproject.toml is a config file, not a database. It should be read only.
-
a docs link on pypi.org is 404. Luckily there are two docs links. Should really just fix that, but it's left like that to see if anyone notices. No one did.
Very wise idea. And if you want to up your game, can validate the yaml against a schema.
Check out strictyaml
The author is ahead of his time. Uses validated yaml to build stories and weave those into web sites.
Unfortunately the author also does the same with strictyaml tests. Can get frustrating cause the tests are too simple.