PEP 735 – Dependency Groups in pyproject.toml | peps.python.org
peps.python.org
This PEP specifies a mechanism for storing package requirements in pyproject.toml files such that they are not included in any built distribution of the project.

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?!

  • logging_strict@programming.devOP
    1·
    7 days ago

    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.0

    Found this out when investigating pep639 support issues. Long story short not yet fully implemented.