nix: update flake inputs

[evanrichter]

also removed non-existent crane flake input overrides

This was just a simple nix flake update

[the-mikedavis]

Thanks!

[nanzhong]

Just wanted to give a heads up that that this will currently fail to build via the flake (at least on macos) until #8962 is applied (rescript grammar failing to build), this is related to nixpkgs-unstable bumping to clang 16 in the stdenv.

Not sure if this has been brought up before, but would it make sense to add a CI step to actually build helix so that build failures like this can be caught via automation?

[pascalkuthe]

we ofcourse have a ci step that builds helix (including grammars) but that runs on the distros that GH runner provide so we can't catch "grammar won't work with distro/compiler configuration X" this way (and we can't change that without making CI really complicated an slow)

[nanzhong]

Are you referring to https://github.com/helix-editor/helix/blob/master/.github/workflows/cachix.yml? Just to clarify I'm talking about building helix using the flake. To me that workflow looks like it's doing just that (though it's not matrixed on os like the build workflow), but it only runs on the master branch post merge. My question was more whether that should run on PRs as well (and tangentially whether it should also be matrixed on OS) to verify that the flake actually builds; I think in theory that should have caught this failure.

I guess whether this additional overhead is worth it is dependent on how much nix is intended to be supported or expected to be used for helix.

[pascalkuthe]

Ah no I didn't mean nix specifically. I meant we build helix in CI. The official build process for development uses cargo and that is what we test (on the GJ runner). To me nix is just another distro/package manger and shouldn't affect whether we merge PRs.