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.

you are viewing a single comment's thread
view the rest of the comments

[–] spoonbill 2 points 4 hours ago (1 children)

Why do you need to have a centralized pyproject.toml?

[–] logging_strict 1 points 3 hours ago (1 children)

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?

[–] [email protected] 1 points 55 minutes ago

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.