Option aliases are parsed incorrectly

[llakala]

Describe the bug
I'm using the lib function mkAliasOptionModule to provide easy access to home-manager config via an option alias. It turns this:

home-manager.users.emanresu.foo.bar = true;

Into this:

hm.foo.bar = true;

In case it's helpful, here's how I declare the alias:

imports =
[
  ( lib.mkAliasOptionModule ["hm"] ["home-manager" "users" "emanresu"] ) 
];

I've set up Nixd to give me autocomplete for home-manager, and it works perfectly whenever I use the unaliased form, like this:

But when I use the alias, it only shows the first value, and doesn't provide completion for any of the others:

I would expect nixd to handle these kinds of aliases normally.

Configuration
I use Home-Manager as a module, so to get Nixd to undestand it, I set it up like this:

home-manager.users.emanresu.programs.helix.languages.language-server = 
{
  nixd.config.nixd.options =
  let
    myOptions = "(builtins.getFlake \"${self}\").nixosConfigurations.MYHOSTNAME.options";
  in
  {
    nixos.expr = myOptions;
    home-manager.expr = myOptions + ".home-manager.users.type.getSubOptions []";
  };
};

[inclyc]

What does nix-repl show in case of aliased option?

nix-repl> PATH.hm

where PATH is home-manager.expr defined in nixd's configuration.

[llakala]

What does nix-repl show in case of aliased option?

nix-repl> PATH.hm

where PATH is home-manager.expr defined in nixd's configuration.

Interesting. After doing some repl research, it seems that hm is actually not found within the home-manager.expr value. Instead, it's found within nixos.expr, and seems to be imported automatically, but incorrectly.

For other, non-aliased values, using getSubOptions seems to work perfectly. I can do this for home-manager, as previously established:

nix-repl> nixosConfigurations.HOSTNAME.options.home-manager.users.type.getSubOptions []
{
  _module = { ... };
  accounts = { ... };
  assertions = { ... };
  dconf = { ... };
  editorconfig = { ... };
  fonts = { ... };
  gtk = { ... };
  home = { ... };
  home-files = { ... };
  i18n = { ... };
# etc, more home-manager options
}

But, I can do the same thing with nixos to get all of its options:

nix-repl> nixosConfigurations.HOSTNAME.type.getSubOptions []
{
  _module = { ... };
  appstream = { ... };
  assertions = { ... };
  baseVars = { ... };
  boot = { ... };
  console = { ... };
  containers = { ... };
  custom = { ... };
  docker-containers = { ... };
  documentation = { ... };
  dysnomia = { ... };
  ec2 = { ... };
  environment = { ... };
  fileSystems = { ... };
  fonts = { ... };
  gtk = { ... };
  hardware = { ... };
  hm = { ... };
  home-manager = { ... };
# etc, more nixos options

HOWEVER, this same process does not provide all the options for the hm alias:

nix-repl> nixosConfigurations.HOSTNAME.options.hm.type.getSubOptions []
{
  _module = { ... };
}

This is the behavior we were seeing with the completions. It seems like getSubOptions fails to provide the sub-options for an alias. i'm not sure what the correct function would be to get these for an alias (or whether that function even exists). If it does exist, then nixd could just treat aliased modules differently and use the correct function. If it doesn't exist, I can make an issue in nixpkgs. This feels like buggy behavior, but perhaps there's some intention behind it.

[inclyc]

i'm not sure what the correct function would be to get these for an alias (or whether that function even exists). If it does exist, then nixd could just treat aliased modules differently and use the correct function. If it doesn't exist, I can make an issue in nixpkgs. This feels like buggy behavior, but perhaps there's some intention behind it.

Perhaps we can create an issue in nixpkgs and then inspect how to co-operate with it.