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?!
setuptools maintainers discuss pyproject.toml validation.
"I was under the impression that PyPI implements validation of the distribution files metadata, but if it does, the validation is not very strict. What is validated strictly is the form data that is sent alongside the distribution files. That can be tweaked as needed to support the metadata emitted by existing setuptools releases.
pip is most likely the most permissive consumer of metadata, thus I don’t expect it to do any validation."
https://github.com/pypa/setuptools/issues/4759#issuecomment-2503640532
Here is the spaghetti code doing the validation as of
setuptools-75.8.0Found this out when investigating pep639 support issues. Long story short not yet fully implemented.
Limitations of requirements.txt files
– https://peps.python.org/pep-0735/#limitations-of-requirements-txt-files
The only benefit i can see, is to attempt to bring requirements files into
pyproject.tomland an additional layer to abstract away from pip.^^ this does not keep me awake at night nor is it a substitute for porn
The PEP author’s intentions are good, puts focus on a little discussed topic.
The outcome … questionable
If this is all it’s doing, that’s not enough. Ignores the elephant in the room.
Which are
-
fixing dependency conflicts
-
mutual compatibility
Fixing dependency conflicts would be easier if can work with existing proven tooling. Which acts upon r/w files rather than pyproject.toml, a config file; shouldn’t constantly be updated.
additional layer to abstract away from pip
reqs.txt files are not standardized and pip can read from a
pyproject.toml- which is - usingpip install .there are still many unresolved matters with dependency resolution, but we need to leave
requirements.txtfiles behind.Throwing out an alternative. Not making the assumption that more TOML is better. Cuz the contents of those
requirements.txtfiles are rw, not ro. I seepyproject.tomlas a ro configuration file.Do you agree or should
pyproject.tomlbe rw?Another option, strictly validated YAML.
For the configuration section, before parsing occurs, strict validation occurs against a schema.
TOML vs strictyaml – https://hitchdev.com/strictyaml/why-not/toml/
I didn’t know about StrictYAML, we’re really going in circles lol
TOML is already RW by Poetry, PDM, and uv.
Yeah, but should it be (rw)?
If it’s rw, it’s a database, not a config file.
No software designer thinks … postgreSQL, sqlite, mariadb, duckdb, … nah TOML
Or at least yaml turns out to be not a strange suggestion
-
