this post was submitted on 23 Nov 2024
9 points (90.9% liked)

Python

6426 readers
22 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
9
constraint vs requirement. What's the difference? (programming.dev)
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]
27 comments fedilink hide all child comments
 

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
[–] [email protected] 1 points 6 days ago (1 children)

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.

[–] [email protected] 1 points 6 days ago* (last edited 6 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 5 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.

[–] [email protected] 1 points 4 days 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 4 days ago (1 children)

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

[–] [email protected] 1 points 3 days 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.