In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).
Say have docs/requirements-pip-tools.in
-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in
...
The intent is compiling this would produce docs/requirements-pip-tool.txt
But there is confusion as to which flag to use. It’s non-obvious.
constraint
Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!
Does not support:
-
editable mode (-e)
-
extras (e.g. coverage[toml])
Personal preference
-
always organize requirements files in folder(s)
-
don’t prefix requirements files with
requirements-, just doing it here -
DRY principle applies; split out constraints which are shared.
Was working under the assumption that everyone considered constraints (-c) to be non-negotiable required feature.
If only have requirements (-r), in a centralized pyproject.toml, then how to tackle multiple specific dependency hell issues without causing a huge amount of interconnected clutter?
Why do you need to have a centralized pyproject.toml?
Within the context of resolving dependency conflicts, poetry decided pyproject.toml is a great place to put requirements.
This is what people know.
pyproject.toml or venv management should otherwise never come into the conversation.
My personal opinion is: venv, pip, pyenv, pip-tools, and tox are sufficient to manage venvs.
venvs are not required to manage requirement files. It’s a convenience so dev tools are accessible.
Currently the options are: poetry or uv.
With honorable mention to pip-compile-multi, which locks dependencies.
poetry and uv manage venvs… Why?
are you really asking why use 1 tool instead of 5?
venvs and dependency management are such interconnected concepts, I don’t even know how you could sustainably handle them separately.