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

[–] logging_strict 1 points 3 days ago* (last edited 3 days ago) (1 children)

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.

[–] [email protected] 2 points 3 days ago (1 children)

The Python env has been trying this multiple tools approach for decades and consistently delivering a worse experience than languages that pack most things in one tool.

Rust is a bliss to use, largely thanks to cargo that takes care of build, dependencies, locking, tests, publishing etc. You say do one thing and do it well. In my experience they often do one thing in a mediocre way, while forcing users to understand which and how to combine dozens of possible tools in a development environment that keeps changing. It's messy, slow, error prone, and requires constant developer attention.

[–] logging_strict 1 points 1 day ago (1 children)

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.

[–] [email protected] 1 points 1 day ago (1 children)

and despite those differences, uv is essentially cargo for Python, showing it is possible.

[–] logging_strict 1 points 16 hours ago

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.