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.
UNIX philosophy. One tool that does one thing well
Best to have a damn good reason when breaking this principle (e.g. vendoring) or be funded by Money McBags
requirements files are requirements files, not venvs. They may install into venv, but they are not venvs themselves. The only thing a venv provides that is of interest to ur requirements files are: the relative folder path (e.g. ‘.venv’) and python interpreter path. Nothing more. When using tox, the py version is hardcoded, so only need to provide the relative folder path.
The venv management tools we have are sufficient. the problem is not the venv, it’s managing the requirements files.
Your 1 tool suacks just as much as my 5 tools when it comes to managing requirement files. None of them do the job.