NaN-git

> Like mentioned in [#4910 (comment)](https://github.com/NixOS/nix/issues/4910#issuecomment-1214148665), we might want to consider to encode the yaml version into the function somehow. Instead of `fromYAML` it could be named `fromYAML1_2`. In case...

> ## Issues to clarify > [...] > * [ ] show various features and how they map to Nix values > > * [ ] add tests for the...

> I would package it and its dependency in Nixpkgs. I am happy to help with that part if you want. > > I personally am not to concerned about...

I removed rapidyaml as single header file and made it an optional library instead. If the library cannot be found then `builtins.fromYAML` is not available. Rapidyaml is not part of...

> Whether that's even a worthwhile effort, I don't know. Personally I think bootstrapping Nix from source is not an important use case, but packaging by other distros is. Those...

@roberth I implemented option no. 2. Now `configure` fails if rapidyaml is not available unless it is disabled explicitly.

### Lazy evaluation? I have another thought: Would it make sense to make the implementation lazy like in #7249? I think that it won't have a large impact on the...

> ### Reproducibility... > > This is a little concerning. The rapidyaml documentation [says](https://github.com/biojppm/rapidyaml#known-limitations): > > > Also, ryml tends to be on the permissive side where the YAML standard...

I don't think that using `std::random_device` is a good choice. Its behavior is basically undefined: > std::random_device may be implemented in terms of an implementation-defined pseudo-random number engine if a...

> This is already a problem for numbers within the 64-bit range if you make the additional assumption that the bounds are reasonable. > ```bash > nix-repl> 123456789012345678 - builtins.floor...