Closed stasjok closed 2 years ago
If a cache lookup fails then it is invalidated and re-cached. What's wrong with this?
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.
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?
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.
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?