logging_strict

As the quantity and relationships complexity increases so to does the need for management tools to deal with the chaos.

Most Python coders cope by keeping things overly simple. Avoiding complexity at all costs.

Do you fully embrace requirement file complexity or do you avoid it?

1. assume one venv

2. has no way to deal with unavoidable incompatibilities

Which maybe due to: a package becoming unmaintained or overly zealous limiting allowed versions

3. has no way to adapt to security vulnerabilities (e.g. CVE-2024-9287)

4. has no intelligent way to normalize both direct and transitive dependency versions across lock files

Ignoring concurrency.

For a write to be transactional, validate-pyproject would need to be called:

Once prior to the read and again prior to the write.

Is that occurring always?

Haven't checked if validate-pyproject has an API, so can be called on a str rather than only a file.

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