Packages with comments in spago.yaml might break

[bakhtiyarneyman]

We are trying to parse spago.yaml using fromYAML but the latter only supports the skeletal syntax that spago.lock uses.

purescript-overlay/nix/build-spago-lock.nix

Line 188 in c7d9df1

then lib.attrByPath ["package" "publish" "version"] defaultVersion (fromYAML (builtins.readFile "${drv.out}/spago.yaml"))

For now we should probably just emit 0.0.0 until there is a better solution. I'm not holding my breath for this PR but it seems the be the right way of doing things.

NixOS/nix#7340

[thomashoneyman]

Ah, yes. This is a known limitation from when we purely parsed the lock file. We’ll have to switch to some other way of parsing yaml that’s able to handle comments — most likely it’ll have to be an import-from-derivation of some tool that can parse yaml and produce JSON

[bakhtiyarneyman]

From what I have read, the IFD feature is a performance and DX footgun. It could block parallelized building on the single-threaded evaluator (references below). This means that using purescript-overlay in bigger projects might result in meh developer experience. IMHO a project needs a very compelling reason to use IFDs and emitting the right version number in the nix store path doesn't cut it.

Even more so, I stumbled upon this because as part of my work on running spago tests, I found a need to get the name of the main module of a test, which is present in spago.yaml but not spago.lock. Not being able to parse the YAML using pure nix means that in general case the user has to pass the name of the main module of the test explicitly, which means duplication. Even this I find preferable to using IFDs.

Alternatives

If a pure-purescript implementation of yaml parsing existed maybe we could have used it via PureNix, but the only one I found is using FFI.

References:

• A comment from edolstra from 2017 about IFDs
• A blog post about IFDs