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 (2 children)

my personal preference is a pyproject.toml over that mess

[–] [email protected] 2 points 6 days ago* (last edited 6 days ago)

my position is it's not messy enough

Lets start off by admitting what the goal is.

We all want to avoid dependency hell.

Our primary interest is not merely cleaning up the mess of requirements files.

Cleaning up the mess results in some unintended consequences:

  1. noise
  2. complexity
  3. confusion

noise

All the requirements information is in one place. Sounds great until want to tackle and document very specific issues.

Like when Sphinx dropped support for py39, myst-parser restricted the Sphinx upper bound version, fixed it in a commit, but did not create a release.

Or cffi, every single commit just blows our mind. Adding support for things we all want. So want to set a lower bound cffi version.

My point being, these are all specific issues and should be dealt with separately. And when it's no longer relevant, know exactly what to remove. Zero noise.

complexity

When things go horribly wrong, the wrapper gets in the way. So now have to deal with both the wrapper and the issue. So there is both a learning curve, an API interface, and increased required know how.

The simple answer here is, do not do that.

confusion

When a dependency hell issue arises, have to deal with that and find ourselves drawn to poetry or uv documentation. The issue has nothing to do with either. But we are looking towards them to see how others solve it, in the poetry or uv way.

The only know-how that should be needed is whats in the pip docs.

Whats ur suggestion?

Would prefer to deal with dependency hell before it happens. To do this, the requirements files are broken up, so they are easier to deal with.

Centralizing everything into pyproject.toml does the opposite.

Rather than dealing with the issue beforehand, get to deal with it good and hard afterwards.

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

But pyproject.toml supports neither locking nor constraints.

[–] [email protected] 2 points 6 days ago

Woah! Was giving the benefit of the doubt. You blow my mind.

The locking is very very specific to apps and dev environment.

But lacking constraints is like cutting off an arm.

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

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

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

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