Automatically infer extraPlugins used, if your config contains specific functions about nixvim

[GaetanLepage]

I mean we already infer some packages based on config, which is really good. I am pretty sure nvim-cmp sources are inferred from your config and I really think this is good user experience.

This proposal just sets out to allow commands from small plugins too.

To me this is not the same thing. What we do now is enabling a package or plugin which is a dependency (strict or optional) of the plugin you want to configure.
For instance, if I set plugins.lualine.iconsEnabled to true, nixvim will add the nvim-web-devicons plugin to extraPlugins.
In your example, you want to embed a command offered by another plugin in a separate one.

Actually your solution 1 (or a variation of it) seems legit in terms of technical solution.
The only thing is that I cannot get to imagine many examples of such command imports.

One last thing. I am willing to review and test any proposal code. I am really not closed to a solution proposition.
This is not a strong "no" at all. :)
At this stage, I just need to be more convinced of both the usefulness and the feasibility of it.

[Alexnortung]

I think I agree with your points on this one after a lot of thought. It may not be as easy as I had anticipated. I will close this issue, hopefully I might figure something out somehow.

[GaetanLepage]

Hello Alex,
To be perfectly honest, I am not really convinced by such a feature.
Here is why.
Obviously, wanting a better user experience should be our ultimate goal. However, in this case I am not sure it is a good thing.
The reason is the extra added complexity. The latter is dual:

• For us (the developers): Supporting this would lead to complicating the code base and the way our module works. As you pointed out, it would require some pretty advanced techniques which would make nixvim less "straightforward".
  However, I am not at all intrinsically opposed to anything that is harder or more complex to implement. What matters at the end is the user. But still, we have to keep the code base as maintainable as possible.

• For the user: What I personally liked about nixvim when I found out about it, is that it is mostly straightforward:

  • It makes it possible to translate your lua config to nix in a natural way. (Options are the same, they are just translated to lua very naturally).
  • It handles several things thanks to nix that the user can stop worrying about. (I think mostly about the plugin manager and the package dependencies like the language servers).

  But it does not do more than this. And, according to me, this is great. I get what you mean when you say "With this, the user can directly use the plugin without explicitly requiring it". However, to me, you should be explicit about which plugin you want to install on your system. The behavior you want to push seems like the one a neovim distribution would have (such as LunarVim, NvChad...). In those, the chosen paradigm is different as they abstract many more things.
  From what I understand, nixvim is more a simple module that lets the power (and the responsibility) to the user.

This is my own opinion. Obviously, the final word should be Pedro's. I would be glad to hear what @traxys and @pta2002 think about this.

Anyway, thank you for bringing new ideas on the table :)

[Alexnortung]

Thanks for the feedback @GaetanLepage. I just thought this feature would fit nicely in nixvim since we are already utilizing the power of nix.

I totally agree with you that nixvim should be maintainable, and I don't think that the logic is too complex, we just need to change the way things are added and changed, I think.

On the other side, you may be right that this should be in a separate project. However it would be coolest to have the feature in nixvim in some way ;)

And to address that you should be explicit, I think that makes very good sense as Nix is all about being declarative, but that is why I also wanted idea 1, where you could explicitly say, that you want to import a specific command, Nixvim would just handle the dependency management :)

[pta2002]

IMO I mostly agree with what @GaetanLepage said. I think it'd very quickly turn into a maintenance nightmare. The only real way I can see this working would be something like what you initially suggested with the imports, but even then I think it'd very easily become a maintenance nightmare. I think a simpler way to do this would just be plugins.[plugin].extraConfig = plugin: "${plugin}.setup(...)" or something like that, basically a config parameter that lets you define your own config with the plugin's name in scope, acessible via the plugin parameter.

[GaetanLepage]

At first I had not really understood his proposal.
I think it is easier to stay in the NixOS/HM module paradigm (i.e. if I want to use foo, I have to set foo.enable = true;).

I cannot think about a lot of cases where this would be useful...

[Alexnortung]

Okay...

I mean we already infer some packages based on config, which is really good. I am pretty sure nvim-cmp sources are inferred from your config and I really think this is good user experience.

This proposal just sets out to allow commands from small plugins too.

I might try to come up with a solution. And if it doesn't fit in Nixvim I will probably make it some sort of plugin/module in a side project.