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 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”.
especially JS, some packages.json are super long. The sqlite author would blush looking at that
Sure, but why is that a bad thing when you have lots of direct dependencies?
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.
It seems you’re describing a lock file. No one is proposing to use or currently using pyproject.toml as a lock file. And even lock files have well defined schemas, not just an arbitrary JSON-like object.
There’s a few edge cases on parsing dependency urls. So it’s not completely black and white.
just have to read over to pip-compile-multi to see that. (i have high praise for that project don’t get me wrong)
then i’m misunderstanding what data
dependencies groupsare supposed to be storing. Just the equivalent of requirements.in files and mapping that to a target? And no-c(constraints) support?!Feels like tying one of hands behind our back.
see https://packaging.python.org/en/latest/specifications/dependency-groups/#dependency-groups
It’s not schemaless at all, it’s a dictionary of string to string. Not that complex.
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.
I’m not sure what you’re talking about. My point was that dependency definitions in pyproject.toml aren’t schemaless.