this post was submitted on 17 Jan 2025
13 points (84.2% liked)

Python

6580 readers
63 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
13
PEP 735 does dependency group solve anything? (peps.python.org)
submitted 2 weeks ago by logging_strict to c/python
28 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] 3 points 1 week ago (14 children)

You have a strange definition of "database". Almost every language I touch on a daily basis (JS, Rust, C#) uses their package meta file to declare dependencies as well, yet none of those languages treat it as a "database".

[–] logging_strict 1 points 1 week ago (10 children)

In this super specific case, the data that is being worked with is a many list of dict. A schema-less table. There would be frequent updates to this data. As package versions are upgraded, fixes are made, and security patches are added.

[–] [email protected] 1 points 1 week ago (5 children)

It's not schemaless at all, it's a dictionary of string to string. Not that complex.

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

The strictyaml schema holds a pinch of nuance.

The value argument is automagically coersed to a str. Which is nice; since the field value can be either integer or str. And i want a str, not an int.

A Rust solution would be superior, but the Python API is reasonable; not bad at all.

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

I'm not sure what you're talking about. My point was that dependency definitions in pyproject.toml aren't schemaless.

[–] logging_strict 0 points 1 week ago (1 children)

strict schema and a spec are not the same. package pyproject-validate can check if a pyproject.toml follows the spec, but not be using a strict schema.

A schema is similar to using Rust. Every element is strictly typed. Is that an int or a str is not enforced by a spec

If there was a strict schema, package pyproject-validate would be unnecessary

[–] [email protected] 1 points 1 week ago* (last edited 1 week ago) (1 children)

Wait. So there's a tool that allows you to validate pyproject.toml files (since this file can be extended by any tool), and that somehow proves that dependency declarations in pyproject.toml are schemaless? They literally use a JSON Schema for validating exactly this: https://validate-pyproject.readthedocs.io/en/latest/json-schemas.html

[–] logging_strict 1 points 1 week ago

Ignoring concurrency.

For a write to be transactional, validate-pyproject would need to be called:

Once prior to the read and again prior to the write.

Is that occurring always?

Haven't checked if validate-pyproject has an API, so can be called on a str rather than only a file.

load more comments (3 replies)
load more comments (7 replies)
load more comments (10 replies)