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?!
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.
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
Wait. So there’s a tool that allows you to validate
pyproject.tomlfiles (since this file can be extended by any tool), and that somehow proves that dependency declarations inpyproject.tomlare schemaless? They literally use a JSON Schema for validating exactly this: https://validate-pyproject.readthedocs.io/en/latest/json-schemas.html