Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option-completion with mk*-functions in NixOS modules? #104

Open
Ma27 opened this issue Aug 29, 2023 · 2 comments
Open

Option-completion with mk*-functions in NixOS modules? #104

Ma27 opened this issue Aug 29, 2023 · 2 comments
Labels
A-ty Area: type system C-feature Catagory: feature

Comments

@Ma27
Copy link
Contributor

Ma27 commented Aug 29, 2023

While the trivial case of

{ config, lib, ... }:

with lib;

let cfg = config.foo.bar; in
{
  config = {
    # completion here, yay!
  };
}

works fine, but the case that's mostly used for modules, i.e. config = mkIf cfg.enable doesn't work.

I assume that this is because

"config": (#config),
expects an attribute-set with options and not a function-call with an attr-set as argument.

One trivial hack would be to perform completion of options (or attr-sets defined in ty::known) on the attr-set that is an argument to the lambda invocation on config (i.e. to just complete options by convention inside the second argument to mkIf in the example above). This would probably cover ~95% of all cases, but is rather dirty (which is one of the reasons why I'm opening an issue to discuss this first)[1].

However, this doesn't account for more sophisticated examples such as config = mkMerge [ ... ]; or

{ lib, ... }: {
  config = {
    systemd = mkMerge [
      (mkIf true {
        # completion here?
      })
    ];
  };
}

I'm not sure if it's even possible to get that far without implementing even more evaluation logic (AFAIU right now we only evaluate Nix code to gather information about NixOS options), so I'm not sure if that's desirable in this project (second reason for the issue).

Finally, I'd like to say thank you very much for this beautiful tool, it's a huge improvement when working on Nix code these days!

[1] It'd also be possible to just check for the next attr-set in the AST to cover cases like apps = nixpkgs.lib.genAttrs systems (system: { myapp = { /* completion here */ }; }).

@oxalica oxalica added A-ty Area: type system C-feature Catagory: feature labels Sep 2, 2023
@oxalica
Copy link
Owner

oxalica commented Sep 2, 2023

If we can make mk* typed, it's possible to infer argument types through the result type. Maybe we can inject some common function types inside the lib parameter, but that's tedious and needs regular maintenance. And of course, we do not implemented polymorphic types yet.

One trivial hack would be to perform completion of options (or attr-sets defined in ty::known) on the attr-set that is an argument to the lambda invocation on config (i.e. to just complete options by convention inside the second argument to mkIf in the example above).

I'm afraid if it would produce too many false-positives. Attrsets are quite common for various usages, not always as configs.

@DrymarchonShaun
Copy link

DrymarchonShaun commented Sep 21, 2023

EDIT: going to make a separate issue, I don't think this is what I'm experiencing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ty Area: type system C-feature Catagory: feature
Projects
None yet
Development

No branches or pull requests

3 participants