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_strictOP
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    20 hours 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

    • FooBarrington@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      19 hours ago

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

      • logging_strictOP
        link
        fedilink
        arrow-up
        1
        ·
        14 hours ago

        especially JS, some packages.json are super long. The sqlite author would blush looking at that

      • logging_strictOP
        link
        fedilink
        arrow-up
        1
        ·
        14 hours ago

        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.

        • Eager Eagle@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          14 hours ago

          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.

          • logging_strictOP
            link
            fedilink
            arrow-up
            1
            ·
            13 hours ago

            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.

            • FooBarrington@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              13 hours ago

              I’m not sure what you’re talking about. My point was that dependency definitions in pyproject.toml aren’t schemaless.

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      20 hours ago

      it’s a config file that should be readable and writeable by both humans and tools. So yeah, it makes sense.

      And I don’t lile yaml personally, so that’s a plus to me. My pet peeve is never knowing what names before a colon are part of the schema and which ones are user-defined. Even with strictyaml, reading the nesting only through indentation is harder than in toml.

      • logging_strictOP
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        14 hours ago

        You are not wrong, yaml can be confusing.

        Recently got tripped up on sequence of mapping of mapping. Which is just a simple list of records.

        But for the life of me, couldn’t get a simple example working.

        Ended up reversed the logic.

        Instead of parsing a yaml str. Created the sample list of dict and asked strictyaml to produce the yaml str.

        Turns out the record is indented four spaces, not two.

        - file: "great_file_name_0.yml"
            key_0: "value 0"
        - file: "great_file_name_1.yml"
            key_0: "value 0"
        

        Something like ^^. That is a yaml database. It has records, a schema, and can be safely validated!

        The strictyaml documentation covers ridiculously simple cases. There are no practical examples. So it was no help.

        Parser kept complaining about duplicate keys.

        • Eager Eagle@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          8 hours ago

          It has records, a schema, and can be safely validated!

          uh… a database implies use of a database management system. I don’t think saying that a YAML/TOML/JSON/whatever file is a database is very useful, as these files are usually created and modified without any guarantees.

          It’s not even about being incorrect, it’s just not that useful.