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.
A package’s requirements are left unlocked
An app’s requirements are locked
This doesn’t excuse app devs if an requirements.in file is not provided
e.g. pip freeze > requirements.txt and forget
This produces a lock file. Including indirect packages. The direct packages info is lost if a requirements.in is not provided.
