Is it possible for configuration changes to reflect in nixCats without rebuilding?

[meetmangukiya]

The first main feature is the nixCats messaging system, which means you will not need to write ANY lua within your nix files (although you still can), and thus can use all the neovim tools like neodev that make configuring it so wonderful when configuring in your normal ~/.config/nvim

I initially thought it was possible for me to just tell nixCats the config dir in my config repo and it will create a wrapped nvim that will load lua code from the specified directory instead of the standard ~/.config/nvim. But it looks like at the rebuild/switch it copies all the files in the luaPath over to the nix store and link that way, which means I have to build again for the config changes to reflect in the wrapped neovim? I naively tried to replace the cp -r ${luaPath}/* $out/ with ln -s ${luaPath} $out/ but that didn't really work(probably because nix wants to know definite hashes of the directories?).

In summary, is it possible to have live loading of lua code without having to rebuild nixcats if there is no nix change?

[BirdeeHub]

nixCats-nvim/flake.nix

Line 339 in cd8e419

wrapRc = false;

:h nixCats.flake.outputs.settings

^ documentation

Yes, with wrapRc option. Obviously if you change any nix code you will still have to rebuild.

The quick tip in the help I linked is how I use the option. Basically, I just launch the version with wrapRc = false when im messing around with lua, and then rebuild when im done and go back to using the one with wrapRc = true so that it imports properly on other machines again. (The option just skips copying the directory and then you symlink it yourself)

Its really good for messing around with lua but because it doesnt copy it to the store it obviously wont be included if you do nix run yourconfiglink on another machine, hence why you would want 2 otherwise identical outputs, one with wrapRc = true and the other with wrapRc = false. Personally I have the wrapRc = true one aliased to vi and the wrapRc = false aliased to vim. That way I can use vi . normally, and when I want to mess with lua I can use vim . and see my changes reflected, and then rebuild and go back to using vi .

This has the added benefit that vi . is frozen how it was, meaning if I mess it up completely when messing with my lua in the vim . version I can open up vi . and fix it with a working neovim config rather than reverting all of what I just did just to be able to open the editor.

[BirdeeHub]

Yes, this is a known thing. The wrapper included in nix flake init -t github:BirdeeHub/nixCats-nvim#luaUtils actually does this for you.

nixCats-nvim/nix/nixCatsHelp/luaUtils.txt

Lines 59 to 112 in 646fba4

	---------------------------------------------------------------------------------
	*nixCats.luaUtils.lazy*
	For instructions on using the lazy wrapper, check out this template example!
	Disclaimer, it uses a new lazy option only
	in pkgs.lazy-nvim from the unstable branch
	So you must either use unstable, or use an overlay to use the lazy wrapper
	Use the following command in a new directory and check it out!
	>bash
	nix flake init -t github:BirdeeHub/nixCats-nvim#kickstart-nvim
	<
	Once you understand what is going on to use the lazy wrapper util,
	use lazyCat in the lua utils template!
	The 3 main utilities at require('nixCatsUtils.lazyCat')
	>lua
	--the main wrapper
	function M.setup(pluginTable, nixLazyPath, lazySpecs, lazyCFG)
	-- pluginTable is a table of plugin names, either as a list or as the names
	-- of a table of pluginName = "a string";
	function M.lazyAdd(v, o)
	-- if not nix, return the first thing.
	-- If it is nix, return the second, or nil if not provided.
	-- used for disabling things like lazy build steps on nix when needed
	function M.enableForCategory(v, default)
	-- v will be passed to nixCats function.
	-- If the value fetched by nixCats is nil or false,
	-- return false, otherwise return true
	-- if not loaded by nix, return the default value,
	-- or fall back on the nixCats default value provided by
	-- the require("nixCatsUtils").setup function mentioned above
	<
	The other 2:
	>lua
	-- to help you merge the start and opt lists in require('nixCats').included
	function M.mergePluginTables(table1, table2)
	-- its available if you want it, but it is used in the wrapper on pluginTable
	function M.getTableNamesOrListValues(pluginTable)
	<
	The tutorial:
	>nix
	kickstart-nvim = {
	path = ./kickstart-nvim;
	description = ''
	The entirety of the main init.lua file of kickstart.nvim
	implemented as a nixCats flake. With additional nix items for sanity.
	This is to serve as the tutorial for using the nixCats lazy wrapper.
	'';
	};
	<

It sets this option for you, and does the reset it would have done but in a way that doesnt remove the config and treesitter grammars.

It also defines the plugin dev path in such a way that if you give it a list of plugin names to include (provided by require('nixCats').pawsible.allPlugins.start and require('nixCats').pawsible.allPlugins.opt and viewable with :NixCatsPawsible) it will look for them locally instead of downloading them, although preventing the rtp reset is the important part, this part can be skipped just fine if you choose to allow lazy to continue being the thing that downloads the plugins. (Using lazy to download them may occasionally cause failed build steps, which can be fixed either via adding missing dependencies to sharedLibraries and lspsAndRuntimeDeps sections, or downloading the thing that failed via nix and giving the wrapper its name)

You can see the implementation of that wrapper and its usage,

Usage can be seen here:

nix flake init -t github:BirdeeHub/nixCats-nvim#kickstart-nvim

https://github.com/BirdeeHub/nixCats-nvim/blob/646fba4e8c2aededf902c903a45cb3017f937916/nix/templates/kickstart-nvim/init.lua

(some of the things in that file are a little out of date, but everything about the lazy wrapper in it is correct, all that info is in the big banner comments, it will at least show you how to use the functions provided by the wrapper.)

(For lsps, there is a help page and a template for that too, and you can also take a look at the example in the main example config at root level of this repo at lua/myLuaConfig/LSPs. If you know how to use lspconfig it wont tell you anything new about lsps but its still helpful nonetheless)

Implementation here:

nixCats-nvim/nix/templates/luaUtils/lua/nixCatsUtils/lazyCat.lua

Lines 42 to 136 in 646fba4

	function M.setup(pluginTable, nixLazyPath, lazySpecs, lazyCFG)
	local function regularLazyDownload()
	local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
	if not vim.loop.fs_stat(lazypath) then
	vim.fn.system {
	'git',
	'clone',
	'--filter=blob:none',
	'https://github.com/folke/lazy.nvim.git',
	'--branch=stable', -- latest stable release
	lazypath,
	}
	end
	return lazypath
	end
	local nixCatsPath = vim.g[ [[nixCats-special-rtp-entry-nixCats]] ]
	local lazypath
	if nixCatsPath == nil then
	lazypath = regularLazyDownload()
	vim.opt.rtp:prepend(lazypath)
	else
	local grammarDir = require('nixCats').pawsible.allPlugins.ts_grammar_plugin
	local myNeovimPackages = vim.g[ [[nixCats-special-rtp-entry-vimPackDir]] ] .. "/pack/myNeovimPackages"
	local nixCatsConfigDir = require('nixCats').get([[nixCats_store_config_location]])
	lazypath = nixLazyPath
	if lazypath == nil then
	lazypath = regularLazyDownload()
	end
	if type(lazyCFG) ~= "table" then
	lazyCFG = {}
	end
	if lazyCFG.performance == nil then
	lazyCFG.performance = {}
	end
	if lazyCFG.performance.rtp == nil then
	lazyCFG.performance.rtp = {}
	end
	lazyCFG.performance.rtp.reset = false
	vim.opt.rtp = {
	nixCatsConfigDir,
	nixCatsPath,
	grammarDir,
	vim.fn.stdpath("data") .. "/site",
	lazypath,
	vim.env.VIMRUNTIME,
	vim.fn.fnamemodify(vim.v.progpath, ":p:h:h") .. "/lib/nvim",
	nixCatsConfigDir .. "/after",
	}
	if lazyCFG.dev == nil then
	lazyCFG.dev = {}
	end
	local oldPath = lazyCFG.dev.path
	lazyCFG.dev.path = function(plugin)
	local path = nil
	if type(oldPath) == "string" and vim.fn.isdirectory(oldPath .. "/" .. plugin.name) == 1 then
	path = oldPath .. "/" .. plugin.name
	elseif type(oldPath) == "function" then
	path = oldPath(plugin)
	if type(path) ~= "string" then
	path = nil
	end
	end
	if path == nil then
	if vim.fn.isdirectory(myNeovimPackages .. "/start/" .. plugin.name) == 1 then
	path = myNeovimPackages .. "/start/" .. plugin.name
	elseif vim.fn.isdirectory(myNeovimPackages .. "/opt/" .. plugin.name) == 1 then
	path = myNeovimPackages .. "/opt/" .. plugin.name
	else
	path = "~/projects/" .. plugin.name
	end
	end
	return path
	end
	if lazyCFG.dev.patterns == nil or type(lazyCFG.dev.patterns) ~= 'table' then
	lazyCFG.dev.patterns = M.getTableNamesOrListValues(pluginTable)
	else
	local toInclude
	toInclude = lazyCFG.dev.patterns
	vim.list_extend(toInclude, M.getTableNamesOrListValues(pluginTable))
	lazyCFG.dev.patterns = toInclude
	end
	end
	require('lazy').setup(lazySpecs, lazyCFG)
	end

As you can see it simply sets performance.rtp.reset = false, resets the rtp itself to include the nix provided paths still (other than the plugin path), and then sets dev.patterns and dev.path appropriately based on the list of names it is passed.

[BirdeeHub]

Also, thanks for inspiring the new option :) I can now include unwrappedCfgPath = "/home/birdee/birdeeSystems/common/birdeevim"; instead of symlinking that directory to my ~/.config directory. Its a small difference really but a good one.

Of course, this option is still only useful for fast iteration, as on another machine, if I did nix run github:BirdeeHub/birdeeSystems#testvim that file wouldnt be there and thus it would have no config, so I would want to run the one with wrapRc = true, nix run github:BirdeeHub/birdeeSystems#birdeeViminstead.

[meetmangukiya]

For the runnability, maybe just dont commit wrapRc = false; unwrappedCfgPath = "" part and have that in a patch or stash locally. Not much difference really, just a workflow kind of thing maybe? Haven't really used stacked git before, but I think it can be relevant for something like that.

[BirdeeHub]

I did that for a while but it was easier for me to just have 2 outputs, 1 with each, which include the same categories but with the 1 different setting

I factored it out so that I only have to change it 1 time but thats what nixCats and regularCats outputs in the example flake.nix is, just fully typed out

Heres how I factored it out (optional, you could just include the same categories in each):

https://github.com/BirdeeHub/birdeeSystems/blob/410a8f7959c3798b13c1944df245233cee8547ae/common/birdeevim/default.nix#L338C1-L379C5

I have categories and settings factored out like this

and then I just update with // in packageDefinitions

https://github.com/BirdeeHub/birdeeSystems/blob/410a8f7959c3798b13c1944df245233cee8547ae/common/birdeevim/default.nix#L406-L424

and then I have 2 outputs, 1 named birdeeVim and the other named testvim, one with wrapRc = true and one with wrapRc = false

I actually have both of them installed to my user, when I want the wrapped one I use vi and when I want the unwrapped one I use vim

That way I dont have to mess around with git

But yeah you can just output as many different versions of your config as you want which comes in handy for this :) mine has like 6 or 7 or something, some of which are installed some which arent, but all are exported from my system flake to be used on other machines.

[meetmangukiya]

Yeah, I will checkout how you are configuring it. Thanks for all the answers here!

[BirdeeHub]

An aside because I think you also mentioned another thing

If your Lua config is in a separate repo you can still put it in there you just have to import the repo. Just put it in flake inputs and put the input in the LuaPath variable. You could even do sub paths of said other repo with "${inputs.theinput}/some/subpath".

However this wouldn't solve the live update thing, because that particular version of said other repo is now in the store, so you would still need to use the wrapRc option or rebuild.

LuaPath option can only accept store paths, this is a hard limit of derivations. Derivations are built in a sandbox that doesn't have access to the rest of the filesystem (or the internet, although you can supposedly do some magic with fixed output derivations to get internet, you just have to specify the resulting hash of the final output of the derivation, and it will fail if it doesn't match. Pretty sure this is how they do some of the npm stuff. Normally the hash is of the derivation instructions but for fixed output ones, the hash is of the result.)