-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vim-addon-nix seems to no longer work with neovim #54585
Comments
Do you have any idea why it would try to write to $HOME? |
Sadly, no idea. I never configured All I know is that the issue started occuring within past 2 or so months (that’s when I last successfully managed to update my system with |
this suggests vam is installing all missing plugins (in $HOME) Maybe vam plugin installation should be disabled when generating rplugins manifest ? |
I'm not sure why its doing that anyways. Does it just do that on every startup without any user input? Seems like that would slow down startup significantly. |
Apparently the nix/vam instrumentation installs things at each startup nixpkgs/pkgs/misc/vim-plugins/vim-utils.nix Lines 285 to 295 in 5aeaedc
Honestly, I have a hard time understanding what happens here. |
The simple, stupid solution would be to just do |
It also attempts to download missing plugins and the vim-pi repo in the sandbox... |
Weird. I thought the point of managing plugins through nix was that plugins are fetched by nix. |
What is the easiest solution to have working
@timokau where do I need to put this? |
I ended up commenting out offending plugins. |
I have no idea how to fix this, I don't know enough about VAM and don't want to spend too much time reading up on it. If neovim startup fails without internet access, that looks like a bug to me. Should we just skip rplugin generation when using vam? @MarcWeber maybe you have an opinion. |
I recommend git bisect to see what broke it. VAM uses vim-pi (vim package index) to install packages. neovim has some code to generate interface .vim files or such (commands/mappings lazy load stuff). vim-addon-nix eventually pulls some dependencies such "dependencies" : { "vim-addon-mw-utils": {}, "tlib": {}, "vim-addon-actions": {}, "vim-addon-completion": {}, "vim-addon-goto-thing-at-cursor": {}, "vim-addon-errorformats": {} }, which also could cause the failure. But I don't see how they are related to the derivation
put such in ./test.nix then run nix-build ./default.nix and use git bisect. If missing HOME is the problem then just mkdir -p fake-home. export HOME= |
We know what caused this: It was me adding the functionality of generating the remote-plugin manifest in #53084. So we now start neovim once during build (with the plugin RC) to generate the remote plugin manifest. That fails with vam because it tries to go online for some reason. |
If nobody is willing to look into how to make the rplugin manifest generation work with VAM (I'm not), we can simply make sure the failure doesn't break the build. In that case vam plugins would work as before, while other plugin mechanisms could make use of the rplugin manifest generation. |
The only reason why VAM goes online is missing dependencies. So I suggest removing all plugins, trying to build the plugin with VAM only to see whether it works, then adding one plugin after the next to find out which one is missing dependencies / source. The vimrc nix implementation manually registers plugins and nix store paths to make VAM avoid downloading the plugins. In my personal case it looks like this: |
Plugin: vim-pi and and Target: .. lines are generated by plugin info and installation code from VAM. |
So the issue is probably that It would be nice to have a way to tell vam not to do that. Instead it should hard-fail, giving an error message that a dependency couldn't be satisfied. |
Yes the "Generating remote plugin manifest" line is where neovim gets started with a vimrc containing the plugin configuration (basically the final vimrc minus the |
env_vars
/nix/store/jf6m2w0fqca4119h4klwv56sbayyzi73-vimrc
|
https://github.com/MarcWeber/vim-addon-vim2nix This is the tool I wrote back then honoring dependencies. its trivial -> The .vimrc I showed has a function tilling VAM about the location of a plugin. If it doesn't exist echoe and make vim exit with exit code ? https://mawercer.de/tmp/tmp/sample.vim However after installing :ActivateAddon allows laziy installing plugins and make it work. Thus if $out != "" && plugin_not_registerered then show error? |
@nagisa Do you think the hints I gave are enough to try such patch to understand whether VAM is missing a dependency and which one ? |
"Failure only during nix build" is basically what is happening now, just without a nice error message. I think the ideal would be if only plugins registered by nix would refuse automatic dependency resolution. So some way of telling vam "I know what I'm doing by registering this plugin, if it doesn't look right to you I messed up". That way users can still do whatever they want in their own vimrcs, but we can guarantee that plugins provided by nixpkgs work as they should without any need to install anything at runtime. |
I am not sufficiently knowledgeable about the vim plugin operation or nix packaging to attempt that As I said before, I’ll gladly try trivial modifications and/or commands (such as the |
I looked at the code and found that VAM already says everything which is required:
So the problem is the name missmatch 'vim_tlib' vs tlib. vim-pi meant to be a 'package name index' for vim packages - but not many people joined. |
vim-addon-nix does syntax checking and follows import lines by pressing gf. Maybe there are some more features, by I love them that's why I wrote it. Maybe it still contains syntax. That time I wrote it it was best I could do. The main problem is than Bram never cared about community setting up standards. |
I guess the features of vim-addon-nix should be split into individual repositories (syntax vs gf vs syntax checker) and it should be made optional
|
and there's no I fixed it in my vim config by adding |
I also see this with https://github.com/alok/notational-fzf-vim |
Same with https://github.com/neovim/nvim-lsp/ see this issue I don't have any in depth knowledge of Nix but my 2 cents would be that starting Neovim for the build might not be a good idea in the long run. Many plugins will want to create folders, often for good reasons and following XDG best practices. But right now these plugins can then never be loaded for Maybe it's worth revisiting if the manifest generation is worth keeping #54585 (comment) because it seems to me that a few more manual steps would be better than the current status |
Creating folders alone shouldn't be much of a problem, we could just point |
In my case the issue is solved by simply having And yes, the issue author seemed to be having a particularly terrible day. |
That actually sounds like a bug in the manifest generation 😄. If someone fixes the |
Huh I see I interpreted this code and the added comment
to mean that my own |
Yes, but its still unexpected behaviour that opt plugins do not get manifests. We should either move all plugins to |
I am very inexperienced in all this, so maybe i mixing things up, but isn't HOME already being set to a temp dir here? I was having the same problem you were mentioning with |
You're right, apparently the issue is already fixed on master. I think it would be fine to backport this to latest stable if someone wants to open a PR. |
I marked this as stale due to inactivity. → More info |
The fix should now be in the latest stable release (20.09) as well. I think this is resolved. If you still encounter issues, please leave a comment or reopen. |
Issue description
My
vim.nix
looks like this:if
vim-addon-nix
is uncommented, the build fails with the following error:It appears that something is incompatible/broken in the
vim-addon-nix
addon. It used to work until just recently.Steps to reproduce
The configuration file is described above. Import it into
configuration.nix
and try to build system that is dependent on neovim.Technical details
The text was updated successfully, but these errors were encountered: