You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One immediate advantage of TOML here is that the package namespace is easily visible. With YAML, you have to scroll all the way up to the beginning of the list. Not an easy task with large lock files.
tomllib is also part of the Python standard library, which makes reading TOML files more accessible than YAML.
Lastly, serde_yaml is archived and was never a fantastic option to begin with, IMO.
It depends on unsafe-libyaml which is a C to unsafe Rust transcribed library implementing an outdated YAML version.
The text was updated successfully, but these errors were encountered:
We have been discussing this internally as well. The biggest issue I see is how we make parser backwards compatible but perhaps first trying to read the file as toml and if that fails try yaml is good enough.
Problem description
To my knowledge, the main reason YAML has been chosen for
pixi.lock
was to stay compatible with conda-lock. This goal has been abandoned by now: https://prefix.dev/blog/introducing_multi_env_pixi#the-new-pixilock-format-The main advantage of YAML IMO is that it is nicer with deeply nested structures. This doesn't apply here. Compare e.g. one package in YAML vs TOML:
YAML
TOML
One immediate advantage of TOML here is that the
package
namespace is easily visible. With YAML, you have to scroll all the way up to the beginning of the list. Not an easy task with large lock files.tomllib
is also part of the Python standard library, which makes reading TOML files more accessible than YAML.Lastly, serde_yaml is archived and was never a fantastic option to begin with, IMO.
It depends on unsafe-libyaml which is a C to unsafe Rust transcribed library implementing an outdated YAML version.
The text was updated successfully, but these errors were encountered: