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.
Most languages don’t support packages containing multiple languages (C/C++, Cython, and Python). So Python situation is much more complex.
distutils
setuptools is complex
pip is complex
requirements files are complex
space aliens wrote pytest (and pluggy)
publishing and dependencies are super centralized, depending on pypi.org way too much.
Comparing Rust vs Python is nonsense. Rust is a stricter compiler on top of C. It has to deal with legacy C libraries. It has it very very easy.
and despite those differences, uv is essentially cargo for Python, showing it is possible.
Which begets the question, why inject an additional toolchain into package when not skilled at all in that toolchain. Can’t support issues caused by that toolchain.