Closed montchr closed 1 year ago
The panic should be fixed now in 1a15174958729ca578db517e735479ed5fb963db.
For the flake loading issue, you can try to delete and recreate flake.lock
. If the issue still exists, could you provide the content of flake.nix
, flake.lock
, and the output of nix flake archive --json
?
I dont have a panic but I see too:
LSP[nil_ls] Failed to load flake workspace: Failed to resolve flake inputs from lock file: Missing followed input "nixpkgs_2"
I suspect nil tries to match a flake input to everything in the lockfile but if you dont use follows, you can easily have 3/4 different versions of "nixpkgs" in the lockfile. Could that be it ?
The panic should be fixed now in 1a15174.
Yes, thank you!
For the flake loading issue, you can try to delete and recreate
flake.lock
.
Done, but still getting the "failed to load flake workspace..." messages.
I suspect nil tries to match a flake input to everything in the lockfile but if you dont use follows, you can easily have 3/4 different versions of "nixpkgs" in the lockfile. Could that be it ?
@oxalica @teto Yeah, that seems likely related. I have a few of those un-followed inputs in my flake.lock
(posted below). Usually that applies to nixpkgs
but flake-utils
is another frequent culprit resulting in a bunch of flake-utils_*
inputs. But it looks like the output of nix flake archive --json
doesn't contain any of that numerical input mapping stuff from flake.lock
.
FWIW, after re-creating flake.lock
from scratch, flake-utils_7
is the input reported as missing most consistently. As of https://github.com/montchr/dotfield/commit/d9fd62dbf2f6c4f3f8e61cf0b0f87123de720459 that maps to the flake-utils
input in my flake.nix
. For some reason I pinned another input to follow my flake's flake-utils
-- after removing that, the flake-utils_7
error went away but now we're on to nixos-unstable_2
etc., so I didn't commit that change.
If the issue still exists, could you provide the content of
flake.nix
,flake.lock
, and the output ofnix flake archive --json
?
Here's a gist containing all of those:
https://gist.github.com/montchr/7e1d2dfc333fa1a7982e1a0c1b896bba
flake.nix
and flake.lock
were copied from https://github.com/montchr/dotfield/commit/d9fd62dbf2f6c4f3f8e61cf0b0f87123de720459.
I suspect nil tries to match a flake input to everything in the lockfile but if you dont use follows, you can easily have 3/4 different versions of "nixpkgs" in the lockfile. Could that be it ?
Okay the problem is I misinterpret the followed inputs in flake.lock. The value of nodes' inputs
means the node identifier in nodes
, not an input of root_node
.
I'll fix it later today.
Here's a gist containing all of those:
https://gist.github.com/montchr/7e1d2dfc333fa1a7982e1a0c1b896bba
flake.nix
andflake.lock
were copied from montchr/dotfield@d9fd62d.
I couldn't download github:kleinweb/infra
which seems to be private. But without it, that flake.nix
works fine for me after 015ecacf4301eda59c40ad152109bc8656d49d1e. Could you verify it?
Yes! All is good. Thank you.
Since updating my
nil
flake input in the past week (maybe two weeks ago, but this past Monday seems more accurate), I've been encountering some errors relating to flake inputs in both Emacs and VS Code. Most recently, I updated earlier today since I saw some updates available (I'm excited about the CLI!), but the errors continue.Full output from within VS Code:
And a couple minutes later on
textDocument/completion
:At some point (in Emacs w/
lsp-mode
) I recall seeing a message advising me to runnix flake archive
-- however that doesn't appear to fix the issues.I'm also seeing similar errors on
textDocument/definition
andtextDocument/hover
requests. At a glance they seem likely to have the same root cause so I'll hold off on posting more error logs for now...Aside from these issues (which I'm guessing are related to the recent improvements around flake inputs specifically), other functionality seems to be working as usual (e.g. flattening attrsets refactoring).
Edit: I'm running
aarch64-darwin
by the way.Let me know if you need any more info. Thank you!