lewis6991 / impatient.nvim

Improve startup time for Neovim
MIT License
1.19k stars 28 forks source link

Allow overriding of cache file paths #53

Closed stasjok closed 2 years ago

stasjok commented 2 years ago

I'm using nix package manager and I want to use separate cache for different neovim instances. The problem right now is I manage plugins with nix. All plugin paths are immutable. So impatient.nvim isn't working correctly. Because it implements a module resolution cache. In my case after upgrading all new plugins will be in a new directory. But the previous directory isn't removed immediately. It's immutable and it stays until I clean previous generations of a nix profile. So impatient.nvim checks that there is module in cache, checks that file is valid and it's still the same. My idea is that I will use a separate cache for every immutable plugin pack (for example I'll add a hash to cache file path). This way after upgrading there will be a new cache. But I'll still be able to use already running instance of neovim form previous generation with an old cache. I already tested it by temporary changing vim.env.XDG_CACHE_HOME before requiring impatient but I'd like a more simple approach. Also it's not required, but maybe create a directory if it doesn't exist?

lewis6991 commented 2 years ago

If a cache lookup fails then it is invalidated and re-cached. What's wrong with this?

stasjok commented 2 years ago

If a cache lookup fails then it is invalidated and re-cached. What's wrong with this?

Nothing wrong with this. But in my case cache lookup never fails.

Maybe an example will help? I have plugins in e.g. /nix/store/rlz8rs0si9mdsiqvw8ywgp6hs09y6aad-nvim-data-dir directory. After I upgraded something my new plugin pack will be in, say, /nix/store/0hj82c991xc8kvrjdcbjlp79xyfx1xnh-nvim-data-dir. After I require something impatient.nvim will lookup a module, say, telescope. It founds it in a cache, then checks that file is not changed. But the problem is, old plugin pack /nix/store/rlz8rs0si9mdsiqvw8ywgp6hs09y6aad-nvim-data-dir isn't deleted, so impatient.nvim thinks that it can return a cached copy, but it's a stale copy from old plugin pack.

lewis6991 commented 2 years ago

In that case, why can't you just run :LuaCacheClear via an autocmd each time you update your plugins?

I don't want to add any complicated logic to cover niche cases when a simple workaround exists.

The only thing I can think of in order to invalidate the module-path-cache would be to run a check against runtimepath, however runtimepath is dynamic, so I'm not quite sure what kind of check to do. Perhaps when we require a module we check for an entry in runtimepath where the module would load from, if there isn't one, then invalidate?

stasjok commented 2 years ago

In that case, why can't you just run :LuaCacheClear via an autocmd each time you update your plugins?

I update my plugins not within neovim, but still I probably can save somewhere a path to plugin pack. And check it during startup, then :LuaCacheClear if a path is different from last time. But the reason why I don't want to do that, is that my old copy of neovim will probably be invalid (I often update plugins, but I don't restart my current instance of neovim right away and I want it to work with a cache from old plugin pack). If two instances of neovim with different plugin packs are running at the same time it can result to random errors.

I don't want to add any complicated logic to cover niche cases when a simple workaround exists.

Fair enough.

Perhaps when we require a module we check for an entry in runtimepath where the module would load from, if there isn't one, then invalidate?

It could work but with the same problem with two instances of neovim.

I can close this. I think I can just apply a patch to impatient.nvim during nix build process with required changes.