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
    0·
    1 year ago

    Throwing out an alternative. Not making the assumption that more TOML is better. Cuz the contents of those requirements.txt files are rw, not ro. I see pyproject.toml as a ro configuration file.

    Do you agree or should pyproject.toml be 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/

    • Eager Eagle@lemmy.worldEnglish
      0·
      1 year ago

      I didn’t know about StrictYAML, we’re really going in circles lol

      TOML is already RW by Poetry, PDM, and uv.

      • logging_strict@programming.devOP
        0·
        1 year ago

        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