strict schema and a spec are not the same. package pyproject-validate can check if a pyproject.toml follows the spec, but not be using a strict schema.

A schema is similar to using Rust. Every element is strictly typed. Is that an int or a str is not enforced by a spec

If there was a strict schema, package pyproject-validate would be unnecessary

But it's treated 100% like a crappy CRUD database with no modern features or SQL

it's a file containing records with a strict schema. And nothing else

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.

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.

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

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.

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.

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

• Why

• Why not

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

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/

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.

Would the coke and blow happen for that guy?

Makes sense if i'm that guy

This question is about Python package funding. If world+dog no longer stresses over pip dependency resolution isn't this not extremely valuable? So how to go about getting that package permanently funded. No bs dangling a tiny carrot and insisting on strict justice (reporting milestones ...). Then funding only happens for large projects.

Question on package funding is very legitimate. Have a list of packages that are no longer maintained cuz funding never happened.

Can subsist on crocodile tears. It's a guilty pleasure.

Meaning, if package funding never ever happens, and all that ever happens is never ending articles/threads on Python devs whining about dependency resolution, i'm going to feed that.

Personally not suffering from dependency resolution stress. Everyone else does.

If the available solutions were sufficient there would be no more articles with comment sections filled with war stories, tales of carnage, and loss.

... always comes down to that one guy.

Solve the Python author maintainer funding issue!

Then and only then will i market the package that specifically targeted towards resolving pip dependency resolution issues for package (and app) maintainers.

the old way i am fine with

Never ever made a mistake and install anything system wide

don't need white knights or a nanny state to keep us safe

then they come after our guns, but spoons are always magically safe

To all the fat slob system wide installation cock blocking PR submitters, i say,

Ban spoons!

Shooting ourselves in the foot is a G'd given right! /nosarc

Yes

Whats the alternative you are advocating for?!

We need AA meetings

Hello!

My name is Billy Joe Jim Bob

Hello Billy!

I haven't had a dependency conflict for the past 3 hours. The sleeping problems haven't gone away. As i feel my eye lids drupe, keep thinking about each of my packages and imagining where will the next unresolvable dependency conflicts emerge.

Then i wake up covered in sweat.

Can't keep going on like this. Thank you for listening

Thank you for sharing Billy!

Same thing said another way, be open to using more than one venv