[BUG] derivations cause infinite recursion in toLuaObject

[SuperSandro2000]

Field	Description
Plugin	typos-lsp
Nixpkgs	nixos-unstable
Home Manager	none

• I have read the FAQ and my bug is not listed there.

Description

When adding a derivation inside of plugins.lsp.servers.typos-lsp.settings it is not automatically turned into a store path but an infinite recursion occurs.

The end of the errors is:

       error: stack overflow; max-call-depth exceeded
       at /nix/store/sxfqjpw542sjv2jmnx1fiqn9fg0v6s9m-source/lib/trivial.nix:277:13:
          276|     x:
          277|     y: x // y;
             |             ^
          278|

Minimal, Reproducible Example (MRE)

programs.nixvim = {
  plugins.lsp = {
    enable = true;
    servers = {
      typos-lsp = {
        enable = true;
        settings = {
          init_options.config = pkgs.writeText "typos-lsp-config" /* yaml */ ''
            default.extend-words:
              - mosquitto
          '';
        };
      };
    };
  };
}

Changing the config to :

programs.nixvim = {
  plugins.lsp = {
    enable = true;
    servers = {
      typos-lsp = {
        enable = true;
        settings = {
          init_options.config = toString (pkgs.writeText "typos-lsp-config" /* yaml */ ''
            default.extend-words:
              - mosquitto
          '');
        };
      };
    };
  };
}

works as expected and I would expect that this automatically happens.

Full log: https://gist.github.com/SuperSandro2000/ebe7af677a61337404703b3358f0f35a

[MattSturgeon]

Wh as t would happen if we didn't have a init_options.config option and the definition instead relied on the freeformType?

I agree, the ideal thing would be for derivations to automatically be stringified to their store path, but I think it's also important for this kinda thing to behave consistently throughout nixvim.

For this specific option we could have type = coercedTo package toString str, but if we do this here how do we decide which other places should have similar coercion?

[SuperSandro2000]

We could run mapAttrsRecursive and convert all derivations to strings. Not sure if all plugins use a some wrapper we could unite this under.

[MattSturgeon]

Ah, I haven't studied the stack trace, but this is probably an edge case toLuaObject should be handling.

It's possible the error is happening when we try and print the attrs as a lua string.

[MattSturgeon]

Yes, near the end of the trace it shows toLuaObject runs into infinite recursion within its removeEmptiesRecursive pre-processing helper.