nix: why does it use fetchTree at eval time?

[colemickens]

cc: @the-mikedavis

Quick question about the nix setup for helix. I reported some "bad behavior" internally at Determinate Systems, (to Eelco no less). I was surprised at things not quite being cached and optimistically skipped the way I might have expected.

Anyway, he (and now I) found it surprising that it utilizes fetchTree (eval time) rather than flake inputs.

Is there a reason for this?

Thanks,
Cole

[the-mikedavis]

Although I have used Nix for a while, I can't say I'm very knowledgeable about it 😄

Is the suggestion to have the tree-sitter grammar repos in the inputs section in flake.nix? That seems alright to me if we can do that and also ensure that they're locked at the revisions pinned in languages.toml. But I'm not sure that's possible - wouldn't the locked revisions then live in flake.lock? I don't want to have two sources of truth for the locked revisions (languages.toml and flake.lock).

[colemickens]

cc: @edolstra any chance I could get you to chime in here?

@the-mikedavis can you render out the languages.toml? You can access the locked revs from the flake and interpolate them into the languages.toml, potentially?

[the-mikedavis]

Ideally I want languages.toml to be the source of truth itself rather than have Nix generate / render it since I want the contribution process (for language-support changes especially) to be as straightforward as possible.

In the long run we want to avoid depending on so many different git repos for language support. We would have either a separate repository or an orphan branch in this repository where we would generate the parser.c, vendor the scanner.c (if it exists) and hold the query files for all languages together. Then Helix would clone that repository and compile the grammars you choose. This would cut way down on the disk footprint of a from-source install and probably make the flake much much simpler as well.