search

nix-community / rnix-lsp

WIP Language Server for Nix! [maintainer=@aaronjanse]
MIT License
702 stars 41 forks source link

flake: Bump `nixpkgs` & `flake-utils` #76

Closed Ma27 closed 2 years ago

Ma27 commented 2 years ago

Summary & Motivation

Bump nixpkgs to 21.11 since 21.05 is dead. Also, the nixUnstable from 21.05 doesn't seem to build on Darwin.

Further context

see #71 cc @DieracDelta

Ma27 commented 2 years ago

Also pushed a temp fix for #75, while I'm not too happy about it, there isn't much else we can do about it to unblock folks on macos since it appears to be a NixOS bug.

cc @lilyball @DieracDelta (would be awesome if you could test this on Darwin for me :))

DieracDelta commented 2 years ago

I tested this in two ways on rev 01b3623b49284d87a034676d3f4b298e495190dd on my m1. This is the commit with the gc test enabled for aarch64-darwin. I believe the GC problem I was encountering got fixed shortly after I opened #71 (see Eelco's PR ). I hope this means we can keep the gc test. What I tested on: (1) I checked out the repo, nix built the default package for aarch64-darwin. This built fine on nix 2.5.1. (2) I added this rev to my neovim config and checked that I was getting syntax errors on nix files. Seems to be working.

lilyball commented 2 years ago

The disabled test isn't related to GC, it's a test that fails when Nix is configured to enable the sandbox when calling nix --version from within the sandboxed build environment.

Another option is to set sandboxProfile on the derivation to allow access to the things that nix is improperly breaking on (or to just disable the sandbox in general if you don't want to try and punch small holes in it). This means the derivation will fail to build if sandbox=true on macOS but it will succeed if sandbox=relaxed or if the sandbox is disabled (which is the default). You can see an example of relaxing the sandbox in macvim. This change would have to be done to the derivation in nixpkgs too of course.

I suppose a third option is to make the test explicitly check if nix --version even executes successfully, and if it fails then just skip the test (i.e. return without running the test as there's no way of dynamically marking a test as skipped). Or use a build.rs script that checks for this and sets a --cfg flag that controls whether the test is ignored. But that seems overly complicated.

lilyball commented 2 years ago

I successfully built rnix-lsp on my M1 machine with the nixpkgs input overridden to my pinned recent version of nixpkgs/nixpkgs-unstable (and with sandbox=relaxed). I realize that this overrides one of the changes in this PR, but that does test how I would consume this flake if I switch my local setup from nixpkgs's derivation to the flake (which is tempting but means I'd have to build from source instead of using the nixpkgs binary cache).

I am not set up right now to easily actually test the language server itself (I haven't configured vim for that yet, and I didn't want to change my VSCode user config), but the build is the important part.

lilyball commented 2 years ago

I just did the same on my x86_64-darwin machine for good measure.

Ma27 commented 2 years ago

Another option is to set sandboxProfile on the derivation to allow access to the things that nix is improperly breaking on (or to just disable the sandbox in general if you don't want to try and punch small holes in it). This means the derivation will fail to build if sandbox=true on macOS but it will succeed if sandbox=relaxed or if the sandbox is disabled (which is the default). You can see an example of relaxing the sandbox in macvim. This change would have to be done to the derivation in nixpkgs too of course.

I'm not very keen on maintaining workarounds (at several places) for a Nix bug tbh. In the end this isn't a system/architecture-specific feature, so as long as it doesn't break everywhere we should be fine IMHO.

That said I'd merge this and publish a new release to fix the issue on our end at least.