this post was submitted on 17 Jan 2025
14 points (93.8% liked)

Python

6519 readers
25 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 2 years ago
MODERATORS
jnovinger
erlingur
norambna
14
PEP 735 does dependency group solve anything? (peps.python.org)
submitted 1 day ago by logging_strict to c/python
23 comments fedilink hide all child comments
 

PEP 735 what is it's goal? Does it solve our dependency hell issue?

A deep dive and out comes this limitation

The mutual compatibility of Dependency Groups is not guaranteed.

-- https://peps.python.org/pep-0735/#lockfile-generation

Huh?! Why not?

mutual compatibility or go pound sand!

pip install -r requirements/dev.lock
pip install -r requirements/kit.lock -r requirements/manage.lock

The above code, purposefully, does not afford pip a fighting chance. If there are incompatibilities, it'll come out when trying randomized combinations.

Without a means to test for and guarantee mutual compatibility, end users will always find themselves in dependency hell.

Any combination of requirement files (or dependency groups), intended for the same venv, MUST always work!

What if this is scaled further, instead of one package, a chain of packages?!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 8 points 1 day ago (1 children)

I think you’re expecting this PEP to be something that it is not. It is not supposed to be a full solution to dependency hell (which I’m not really sure that there is). It is supposed to just allow a static method to declare dependencies, notably supporting both Python package and non-Python-package dependencies. There are plenty of use cases for when you might want incompatible sets of dependencies, for a simple example consider a graphics library with both a Vulkan and OpenGL backend. You could reasonably argue that you should allow both to coexist and just select the best one at runtime, but when you’re dealing with native libraries that’s not always possible, and there is no way to make a guarantee about compatibility without excluding all non-pure Python dependencies.

[–] logging_strict 1 points 1 day ago* (last edited 1 day ago)

Wasn't aware that this PEP is including non-Python package dependencies or how that affects dependency resolution.

Managing python dependencies is challenging enough