neovim: expose sideloadInitLua option to control the generation of init.lua

[veselyn]

Description

This pull request tries to resolve #8938.

Checklist

• Change is backwards compatible.

• Code formatted with nix fmt or
  nix-shell -p treefmt nixfmt deadnix keep-sorted nixf-diagnose --run treefmt.

• Code tested through nix run .#tests -- test-all or
  nix-shell --pure tests -A run.all.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.
  • Generate a news entry. See News
  • Basic tests added. See Tests

• If this PR adds an exciting new feature or contains a breaking change.

  • Generate a news entry. See News

[teto]

thanks for trying to tackle this. This wont work depending on the plugins you install that might pull some premade config.

What I think would be clearer for everyone, users and maintainers is an option (not sure how to name it: sideload, wrapConfig I welcome suggestions ) to make explicit the choice of not writing to init.lua but rather to lua/hm-generated.nix. Having a stable path make it easier to debug.

There is another issue I welcome input as well: how to load the generated config ?
We could let the user write the loading from its init.vim but it would be best to default to something working out of the box.

The following enum would cover all bases IMO:

• preload : require hm-generated with -c (this would be the default)
• postload: require hm-generated with --cmd
• user: let the user require it from his imperatie init.lua

Now the annoying bit would be to test all those.

what do you think ?

[veselyn]

What I think would be clearer for everyone, users and maintainers is an option (not sure how to name it: sideload, wrapConfig I welcome suggestions ) to make explicit the choice of not writing to init.lua but rather to lua/hm-generated.nix. Having a stable path make it easier to debug.

Are you thinking of writing it at /nix/store/XXX/lua/hm-generated.nix and including it in the runtime path or symlinking $HOME/.config/nvim/lua/hm-generated.nix? Because the latter will cause trouble for people that manage their configuration outside of Nix by symlinking $HOME/.config/nvim.

There is another issue I welcome input as well: how to load the generated config ? We could let the user write the loading from its init.vim but it would be best to default to something working out of the box.

The following enum would cover all bases IMO:

• preload : require hm-generated with -c (this would be the default)
• postload: require hm-generated with --cmd
• user: let the user require it from his imperatie init.lua

I don't have all the context to provide an opinion. Where does the generated config come from? Does it come purely from the user by, for example, overriding plugin derivations to include custom config?

Another possibility is to use the plugin/ and after/plugin/ runtime directories and essentially package the generated config as a plugin. It might be a better solution than -c considering that -c reads the first file before executing the command.

[teto]

including it in the runtime path or symlinking $HOME/.config/nvim/lua/hm-generated.nix

that's what I had in mind. Until #8933 gets merged, it might trigger issues so we can reference the /nix store directly for now.

I don't have all the context to provide an opinion.

In a nutshell, having an heuristic for wrapping neovim or not confuses users (and maintainers) as users do a change, and all of a sudden neovim is not wrapped anymore and an init.lua tries to be created. And wrapping is nasty because then you have to wrap all your neovim variants (GUIs/wrappers etc).

Another possibility is to use the plugin/ and after/plugin/ runtime directories and essentially package the generated config as a plugin

That's an interesting idea worth exploring. I fear there might be loading order issues etc. In the short term to fix your usecase as well as the linked issue, we can do the simple immediate fix of explicit option to toggle wrapping instead of writing init.lua

If you want to explore loading the config as a plugin in another PR later, that could be interesting as well.

[veselyn]

@teto, I made changes following your suggestion. Could you take a quick look before I write a description for the option and test cases?

[teto]

we might want to avoid engraving "wrap" in the option name if it turns out later we can create a "fake" hm plugin to load the config. I kinda like sideload or sideloadInit.
I know I mentioned "preload", "postload" etc but I would prefer if we kept things simple as starter. We can change it if need arises.
The goal of this PR is already doable without upstream changes, we just need a setting (maybe boolean for now ? we can migrate to an enum when needed) to make it easier for everyone but we dont need to support every scenario.

For instance a user could already set extraMakeWrapperArgs = [ "--cmd 'lua require(${writeText "init.lua" config.programs.neovim.initLua} ] .

[teto]

I would just add enable = !cfg.wrapGeneratedConfigs or in your case (builtins.elem cfg.wrapGeneratedConfigs [ false "user" ] . This way the user can still see the generated config and use it somewhere else but the actual init.lua wont be created.

[teto]

keep only this one and reference lua require ${writeText config.programs.initLua}

[veselyn]

Wouldn't it make more sense to load it before the rest of the files from the runtime path with --cmd instead of -c? That way the load order is closer to what it would be with a regular init.lua file.

[teto]

yes sry

[teto]

ty for taking care of this. I've added some comments. Basically:

• keep initLua as the single source of truth of the generated config
• reuse that initLua in the wrap argument
• for now let's just support one scenario. If users complain, we can adapt before release. Worst case they can already support it themselves. I've documented how to disable the writing of init.lua in https://github.com/nix-community/home-manager/wiki/FAQ#how-to-change-where-home-manager-generates-a-program-configuration-, I can add more details to the neovim page if the need arises

[veselyn]

The tests are still failing and require some more work. I'll pick it up again in the following days.

[teto]

looks good. As for the tests nix run .#tests seemed kinda boggy, you can run make test TEST=<NEOVIM_TEST> instead (eg TEST=neovim-plugin-config).

[veselyn]

I added an extra test case for the sideloading, configured neovim-wrapper-args to load the init.lua file before asserting, and patched the neovim-extra-lua-* cases to pass.