Closed jneem closed 1 month ago
Nice, thanks!
I'll look at how this can be upstreamed.
Some quick thoughts:
{ fenix = inputs.fenix.packages.${system}; }
trick in the Flake because import_nix
implicitly tries adding packages.${system}
to the attribute path you pass to it. It's a bug if that doesn't workMaybe the components arrays could be replaced by a record of booleans, something like:
enabledComponents | "Components to install" = {
rustc | bool | default = true,
cargo | bool | default = true,
rust-std | bool | default = true,
rustfmt | bool | default = false,
rust-docs | bool | default = false,
rust-analyzer | bool | default = false,
clippy | bool | default = false,
miri | bool | default = false,
rust-src | bool | default = false,
}
That's a bit more verbose, but plays nicer with the merge semantics.
You shouldn't need the { fenix = inputs.fenix.packages.${system}; } trick in the Flake
Indeed I don't, thanks! I was so convinced that threading through the system
was going to be annoying that I didn't think to check whether it worked without it...
Maybe the components arrays could be replaced by a record of booleans
Yes, that works nicely. I even did the same to extraTargets, which is nice with autocomplete because the target names are long. I put the result here, since there are now a few files involved.
Fixed by #180
Organist's rust shell uses the rust toolchain from nixpkgs, which is usually fine but lacks a few options. In particular, I often want to
All these options (and more) are supported by nix-community/fenix, so maybe a nice organist interface could be built on top of that?
I had a quick stab at it and got something working, which I will add as an attachment. It requires modifying the template's flake.nix to pass the fenix input like
because I couldn't figure out how else to thread the system through...
project.ncl.txt