constraint vs requirement. What's the difference? (programming.dev)

submitted 3 weeks ago* (last edited 3 weeks ago) by logging_strict@programming.dev to c/python@programming.dev

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

[-] spoonbill@programming.dev 2 points 3 weeks ago

But pyproject.toml supports neither locking nor constraints.

[-] eager_eagle@lemmy.world 2 points 3 weeks ago

Ah true, I had the wrong idea about this constraints file. What's your use case?

[-] logging_strict@programming.dev 1 points 3 weeks ago

That's a loaded question. Would like to avoid answering atm. Would lead to a package release announcement which this post is not; not prepared to right right now.

Instead here is an admittedly unsatisfactory response which i apologize for.

Wish to have the option to, later, take it back and give the straight exact answer which your question deserves.

my use case is your use case and everyone else's use case.

Avoiding dependency hell while keeping things easily manageable. Breaking up complexity into smallest pieces possible. And having a CLI tool to fix what's fixable while reporting on what's not.

My preference is to do this beforehand.

[-] spoonbill@programming.dev 1 points 3 weeks ago

My only use case so far has been fixing broken builds when a package has build-)ldependencies that don't actually work (e.g. a dependency of a dependency breaks stuff). Not super common, but it happens.