support for nix

[mrcjkb]

A really cool project!

I tried signing up with my config, but it fails on step 2, because it can't find the init file.
My init.lua doesn't exist in the dotfiles, because it's generated by nix (which I use to manage plugins).

I'm not sure if it would be feasible to add support for nix, but I've opened this issue just in case 😄

[codicocodes]

I on purpose try to limit users from adding invalid configs, I currently pick the root of your config (supporting monorepos) based on which init file you pick (init.lua / init.vim / .vimrc). Picking an init file is currently required in order to prevent users from adding completely irrelevant repositories.

Do you have any ideas on how your config could be validated and an init file can be selected?

[codicocodes]

Would it be possible to just parse the flake.nix file to figure out all plugins? Is there a way to validate that it is a config and not an unrelated nix project?

Thanks for making the issue btw :D It's hard to build software for use cases that you don't know exist!

[mrcjkb]

Would it be possible to just parse the flake.nix file to figure out all plugins?

That's why I'm not sure if it's feasible to add support for nix.
There are quite a few different ways you can manage plugins with nix (mine is a less conventional one).

• You can declare plugins as flake inputs (like I do).
• Or you can get them from nixpkgs.
• You can also use a module system like nixvim.
• They don't necessarily have to be declared in a flake.nix. They could be in any nix file that is directly or indirectly imported by the flake.nix.
• In Nix, attributes can't always be named the same as plugins are. For example, plenary.nvim becomes plenary-nvim in nix. You would have to evaluate the nix expression to determine the actual plugin name. This might make automatic plugin detection a lot harder for nix.

Do you have any ideas on how your config could be validated and an init file can be selected?

Technically, you don't need an init file. You could also just have files in <nvim-config-dir>/ftplugin/<filetype>.lua or in another directory that neovim picks up as part of the runtimepath (see :help runtimepath).
Perhaps detecting the presence of any of those directories would help? Although this wouldn't work in all cases either.

I guess some other options for nix would be to grep for a neovim configuration like programs.neovim.

I think it would be a good idea to collect different nix use cases here for a while (or to collect unsupported use cases somewhere) before attempting to implement support.
I'll see if I can find some more use cases after work.

[ghostbuster91]

I've just came here report a similar issue. I also think that it is not an easy task to support nix based configurations.

I agree that the best would be to collect various use-cases and maybe start from the simplest ones that could be added with the least effort.

My configuration lives here https://github.com/ghostbuster91/dot-files/tree/master/programs/neovim . It is a mix of different approaches. Some of the plugins are taken directly from the nixpkgs, some are defined as overlays (to override existing ones) and some as new derivations.

I have the init.lua but it gets inlined into home-manager configuration.

[nogweii]

One option you could maybe go for is to optionally support a ready-made metadata dump stored in the repo. (i.e. something like .dotfyle-neovim.json in the root of the repo) That file has all of the information you'd want to find, already rendered. Thus any weird setups or different structures can be supported without you having to build a hundred different parsers, assuming the other person is willing to put in the work to generate such a file.

[codicocodes]

@nogweii See https://github.com/creativenull/dotfyle-metadata.nvim - it's a WIP and not yet supported by Dotfyle, but I will build a parser for it when I'm back from vacation.