Consider using TOML instead of YAML for pixi.lock

[Hofer-Julian]

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

- kind: conda
  name: numpy
  version: 1.26.4
  build: py312he3a82b2_0
  subdir: osx-64
  url: https://conda.anaconda.org/conda-forge/osx-64/numpy-1.26.4-py312he3a82b2_0.conda
  sha256: 6152b73fba3e227afa4952df8753128fc9669bbaf142ee8f9972bf9df3bf8856
  md5: 96c61a21c4276613748dba069554846b
  depends:
  - libblas >=3.9.0,<4.0a0
  - libcblas >=3.9.0,<4.0a0
  - libcxx >=16
  - liblapack >=3.9.0,<4.0a0
  - python >=3.12,<3.13.0a0
  - python_abi 3.12.* *_cp312
  constrains:
  - numpy-base <0a0
  license: BSD-3-Clause
  license_family: BSD
  size: 6990646
  timestamp: 1707226178262

TOML

[[packages]]
build = "py312he3a82b2_0"
constrains = ["numpy-base <0a0"]
depends = ["libblas >=3.9.0,<4.0a0", "libcblas >=3.9.0,<4.0a0", "libcxx >=16", "liblapack >=3.9.0,<4.0a0", "python >=3.12,<3.13.0a0", "python_abi 3.12.* *_cp312"]
kind = "conda"
license = "BSD-3-Clause"
license_family = "BSD"
md5 = "96c61a21c4276613748dba069554846b"
name = "numpy"
sha256 = "6152b73fba3e227afa4952df8753128fc9669bbaf142ee8f9972bf9df3bf8856"
size = 6990646
subdir = "osx-64"
timestamp = 1707226178262
url = "https://conda.anaconda.org/conda-forge/osx-64/numpy-1.26.4-py312he3a82b2_0.conda"
version = "1.26.4"

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.

[baszalmstra]

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.

[ruben-arts]

I would like to move this discussion to rattler as it's a implementation detail and the code for it is in rattler.

[Hofer-Julian]

but perhaps first trying to read the file as toml and if that fails try yaml is good enough

That's what I had in mind as well

[baszalmstra]

I think this is a good idea but Im moving it to the ideas discussions board because I dont know when we'll get to it.