Don't rename modules usually expect the alias-option to not exist; i.e. doRename is responsible for creating the other option ? Even if so, I think that's unrelated.

I've definitely made renames into submodules from outside before (we do this for 50% of nixvim lol), but IIRC making renames out from submodules runs into issues because options.** doesn't exist. Specifically, you run into a _type = "option" object at the submodule-option boundary, options.aSubmodule in the above example.

In nixvim I experimented with resolving the option path recursively, using type.getSubOptions. That was for removal modules, but similar principal.

(This would be (options.aSubmodule._type.getSubOptions options.aSubmodule.loc).someSubmoduleOption in the prior example)

It's also been a while since I looked at the linked code, and IIRC some stuff in that file is broken. Probably the unrelated tryEval hack 😅

Came back to the problem tonight before checking this room again. Seems I came up with a pretty similar solution lol

# repro.nix
let
  lib = import <nixpkgs/lib>;

  budgetIsDefined = value: (builtins.tryEval value).success;
in

lib.evalModules {
  modules = [
    {
      options = {
        # Create a submodule option
        aSubmodule = lib.mkOption {
          type = lib.types.submodule {
            options = {
              # With an inner option
              someSubmoduleOption = lib.mkEnableOption "something" // {
                # Add some warning stuff
                description = "Alias of `aRegularOption`";
                apply = lib.trace "Obsolete option `aSubmodule.someSubmoduleOption` is used. It was renamed to `aRegularOption`.";
                visible = false;
              };
            };
          };

          default = { };
        };

        # Then add a top-level option
        aRegularOption = lib.mkEnableOption "something";
      };
    }

    # Do the actual aliasing
    (
      { config, ... }:
      {
        # We only want to do any of this if the alias option is used
        config = lib.mkIf (budgetIsDefined config.aSubmodule.someSubmoduleOption) {
          aRegularOption = config.aSubmodule.someSubmoduleOption;
        };
      }
    )

    {
      # Now test the alias
      # `nix eval --file repro.nix config.aRegularOption`
      aSubmodule.someSubmoduleOption = true;
    }
  ];
}

The tryEval hack also has a bit of a footgun with type checking though, as incorrect definition errors are eaten up in the same way as when there are no definitions. Don't think there is any way to get more context out of primitive throws though, so this will probably need to be good enough ™️

I really don't recommend using tryEval in this way... It was very situational in nixvim, and even then still probably wasn't the best solution. As you've pointed out, it has plenty of downsides.

I would recommend trying to find the option by recursively walking the "option attr path" (aka loc), checking each attr for lib.isOption and if true, continuing with opt.type.getSubOptions opt.loc.

getOptionRecursive was the part of the file I was hoping you would take inspiration from 😅

Once you have the actual (sub)option you can make use of opt.isDefined with no hacks needed.

I was just writing some assertions, and wanted to show the option defs for an attr-of an option, isolated using lib.modules.mergeAttrDefinitionsWithPrio.

However, mergeAttrDefinitionsWithPrio only includes the value and highestPrio, with no access to files, definitions, definitionsWithLocations, etc.

I came up with a proof of concept that seems to mostly work, however it's failing nix-build lib/tests/release.nix so is probably not lazy enough?

My question: is there an intended way to print definitions/locations for an attr-of-an-option and, if not, how could I improve my patch to make it PR-ready? Or is there an alternative approach I could take?

In this specific scenario, I'm wanting to showDefs a _module.args.* attr, but the concept could apply to any attrsOf or lazyAttrsOf option.