fix(installer): use a tmp config dir during lazy setup

[LostNeophyte]

makes the installation more reliable, lazy.nvim lockfile might have caused problems and sometimes plugins would have wrong versions / installations would fail

[kylo252]

I don't think this is enough, we should try to fully isolate the problem instead of adding a band-aid that will forget about later on why it even existed.

We should keep this function up to date instead

LunarVim/utils/installer/install.sh

Lines 419 to 425 in 01acdde

	function remove_old_cache_files() {
	local lazy_cache="$LUNARVIM_CACHE_DIR/lazy/cache"
	if [ -e "$lazy_cache" ]; then
	msg "Removing old lazy cache file"
	rm -f "$lazy_cache"
	fi
	}

Also, we're already backing up the config directory, so just nuke it (with a warning!) if you think it's problematic.

[LostNeophyte]

the config is no longer moved during the install since #4129
this behavior was annoying, every time you update you need to move your config back, and in some rare cases the config wasn't properly backed up and the script completely deleted it. I also think we shouldn't move the whole .cache/lvim as the undo history is there, just move/delete the luac folder

I think the solution here is to during the initial bootstrap start lvim without loading the config, and the only possible way to that is to use a tmp dir as the config dir

Unless we remove the update capability of the script and do that differently

[kylo252]

the config is no longer moved during the install since #4129
this behavior was annoying, every time you update you need to move your config back

The main problem relates to an old unrecommended behavior that we haven't discouraged enough: the installer should not be used to update an existing config!

There are so many edge cases to try to cover, and it almost never works since those who would try that are users migrating major versions 😞

and in some rare cases the config wasn't properly backed up and the script completely deleted it.

it's pretty hard to get correctly, especially if it's actually a git repo since that wouldn't work all that well with rsync

I also think we shouldn't move the whole .cache/lvim as the undo history is there, just move/delete the luac folder

any other plugins are storing their cache their? also, I'm pretty sure undo should go into state and not cache so we should address that as well.

I think the solution here is to during the initial bootstrap start lvim without loading the config, and the only possible way to that is to use a tmp dir as the config dir

Unless we remove the update capability of the script and do that differently

my plan was always to remove the update from the installer, and it would now especially be a good time that #4270 is getting us closer to a more stable update process.

[LostNeophyte]

my plan was always to remove the update from the installer, and it would now especially be a good time that #4270 is getting us closer to a more stable update process.

I'd love that

should I revert #4129 or use this as a workaround until packaging is done?

[LostNeophyte]

we set undodir and shadafile to cache, it was probably needed before NVIM_APPNAME

LunarVim/lua/lvim/config/settings.lua

Line 7 in 5c7d712

local undodir = join_paths(get_cache_dir(), "undo")

[kylo252]

should I revert #4129 or use this as a workaround until packaging is done?

do the minimum amount of tweaking necessary until packaging is stable

we set undodir and shadafile to cache, it was probably needed before NVIM_APPNAME

LunarVim/lua/lvim/config/settings.lua

Line 7 in 5c7d712

local undodir = join_paths(get_cache_dir(), "undo")

yeah we need to either use state or not modify them (this is technically a breaking change tho, and I'm not sure if we should handle it manually or not)