I think youβre expecting this PEP to be something that it is not. It is not supposed to be a full solution to dependency hell (which Iβm not really sure that there is). It is supposed to just allow a static method to declare dependencies, notably supporting both Python package and non-Python-package dependencies. There are plenty of use cases for when you might want incompatible sets of dependencies, for a simple example consider a graphics library with both a Vulkan and OpenGL backend. You could reasonably argue that you should allow both to coexist and just select the best one at runtime, but when youβre dealing with native libraries thatβs not always possible, and there is no way to make a guarantee about compatibility without excluding all non-pure Python dependencies.
Python
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
Wasn't aware that this PEP is including non-Python package dependencies or how that affects dependency resolution.
Managing python dependencies is challenging enough
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.toml and 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 - using pip install .
there are still many unresolved matters with dependency resolution, but we need to leave requirements.txt files behind.
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/
I didn't know about StrictYAML, we're really going in circles lol
TOML is already RW by Poetry, PDM, and uv.
Not in circles, this is helping for me.
If you have strong support for a rw toml, would like to hear your arguments
Highly suggest reading the strictyaml docs
The author lays out both
Should be required reading for anyone dealing with config files, especially those encountering yaml.
Warning: After reading these, and confirming the examples yourself, seeing packages using pyyaml will come off as lessor
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
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".
especially JS, some packages.json are super long. The sqlite author would blush looking at that
Sure, but why is that a bad thing when you have lots of direct dependencies?
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.
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.
parsing lock files
There's a few edge cases on parsing dependency urls. So it's not completely black and white.
just have to read over to pip-compile-multi to see that. (i have high praise for that project don't get me wrong)
then i'm misunderstanding what data dependencies groups are supposed to be storing. Just the equivalent of requirements.in files and mapping that to a target? And no -c (constraints) support?!
Feels like tying one of hands behind our back.
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.
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.
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.
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.