Go to Definition for attributes of nixpkgs about nil HOT 7 OPEN

This might be what you meant by "limited evaluation in-process", but what about this:

1. On startup, start a nix repl . inside the nixpkgs dir passed by the user as a subprocess.
2. If a goToDefinition request is received from the client and it can't be handled inside the file, run builtins.unsafeGetAttrPos "${attribute-name}" pkgs inside that repl.
3. If we get null back, that attribute is not in nixpkgs, so we return "No definition found"
4. If we get an attrset, we can return that file, line and position
5. For the doc string, we could just return "Nixpkgs attribute" or something like that and the type that we already know.

This is obviously not perfect, but it seems like it would cover the majority of cases and would be a great time-saver already.

from nil.

builtins exclusively refers to the C++ implemented builtins set and functions. They have no Nix sources. According to the description, you means attributes in top-level nixpkgs.

This is quite difficult and requires evaluation, considering stdenv = func args; and stdenv.mkDerivation. Currently I don't come up with any simple way to make it work. But yes, having this feature would be great.

One possible way is to evaluate and cache one or two level attributes for nixpkgs, like nixpkgs-review did. It takes minutes and tens gigs to finish.

BTW: I've thought about type checking. But Nix is highly dynamic. You cannot give reasonable and helpful types for things like callPackage. This makes it hard to infer types of top-level attributes (or simply, whether they are derivations), since all-packages.nix contains tons of callPackages, let along pkgs staging stuff.

from nil.

I know that grep exists, but just by searching it's rather hard to find the actual definition, instead of the hundreds of function calls. But furthermore, I'm not sure this is possible - and would like some input on it.

A workaround that I use is git grep 'hello =' (actually rg as thats much quicker on nixpkgs). That usually works well enough.

from nil.

hey @NobbZ ! While that might work for smaller projects, but I run into the same thing with that strategy:
rg "mkDerivation = " returns a bunch of bogus, for example, because people love to use it as a variable name too, or for wrapper functions.

from nil.

Hi y'all. https://github.com/lf-/nix-doc has a ctags implementation for Nix as of about a year ago. That said, I'm of the opinion that the correct implementation for go to definition is to either:

• do limited evaluation in-process, as https://github.com/aaronjanse/nix-eval-lsp attempted
• write a Nix program that generates an index of nixpkgs and attribute locations, then generate it ahead of time. unsafeGetAttrPos would do much good. This would not be perfect and the main goal is something reasonably acceptable.

The latter has some precedent and would be quite useful as an approach to NixOS options where it seems rather tough to do much meaningful analysis but you can just ask Nix for the data: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-options-doc/default.nix#L123

I speculate that the issues encountered by nixpkgs-review are due to doing something you don't have to do for a language server: evaluating outPath is far more expensive than just getting a list of attributes (c.f. tab completion in nix repl)

from nil.

Oh, also: Puck implemented basically the same thing as nix-doc's plugin with regex crimes in pure Nix (she says using a plugin is "cheating" ;p): https://puck.moe/git/zilch/tree/lib/package/comments.nix

If you do want to use nix-doc's parser stuff inside a Nix invocation to pull the stuff out of Nix, the nix-doc Nix plugin offers a builtins.getDoc someLambda function that will do this for you.

n.b. unfortunately, while Nix has lambda position information in addition to attribute position information, it only exposes the latter as far as I'm aware. The nix-doc plugin quietly exposes a new function builtins.unsafeGetLambdaPos if you need the former by itself without any docs attached.

from nil.

That's not ideal in the face of non evaluable attributes: the more stable strategy is to reuse the Hydra evaluation worker code I think, which has a nicer api than trying to drive a repl, and handles restarting it when Nix crashes after a while. The secret there is that it is actually using the C++ API for it.

from nil.