Is this a vim plugin or a build system?
Right now it tries to be the latter, and consequently cannot be installed by sane build systems such as nix.
Error detected while processing /nix/store/v587bnyaydim9fal8l4p7s2v276lxbxn-vimplugin-nvim-lsp-3bcc387/share/vim-plugins/nvim-lsp/plugin/nvim_lsp.vim:
line 9:
E5108: Error executing lua Vim:E739: Cannot create directory /homeless-shelter: permission denied
Please separate your new build system project in a different repo, so that people who value correctness can use and contribute to a (potential) nvim-lsp plugin ...
https://github.com/NixOS/nixpkgs/pull/76109#issuecomment-594304817
@lifranc
Did you do only install this plugin and load it?
What does "build system" mean here? Is any plugin with a bug a build system?
Error executing lua Vim:E739: Cannot create directory /homeless-shelter: permission denied
Could be an env issue. If you run env, is /homeless-shelter in any env var? (like for xdg config/cache).
@bfredl Any plugin that tries to mkdir when loading is trying to be a build system
There is no env issue. The plugin has no business trying to create any kind of files at that point. Actually, the plugin as no business creating files at all, since is is a plugin. Nix makes sures it cant, and so nvim-lsp makes the neovim build fail when included in its list of plugins.
Most people dont notice since most people dont build their OS correctly.
Is any plugin with a bug a build system?
Dont talk to me like im some fucking idiot
For those not aware, nix is an alternative package manager/basis for a linux distribution with some nice properties, but does require writing a custom build file (derivation) for each module.
@bfredl this looks like it might be an error that can be solved by modifying/patching in the nix derivation, I don't think it's necessarily an issue for nvim-lsp. I use nix, but don't manage my neovim plugins with it. I'm happy to look into this.
As for what /homeless-shelter is: from the nix-manual, during a nix-build:
HOME is set to /homeless-shelter to prevent programs from using /etc/passwd or the like to find the user's home directory, which could cause impurity. Usually, when HOME is set, it is used as the location of the home directory, even if it points to a non-existent path.
FWIW in my experience, it's more effective to submit a PR then expect others who don't use nix to patch their software (I say this as someone who has contributed to both nixpkgs and nvim-lsp).
it's more effective to submit a PR then expect others who don't use nix to patch their software
I began writing my own solution even before opening this issue. As you imply, most people arent interested in a correctly built OS, as it's 'too much work'. Take this more as a 'tip'. Look, vim-lsp project has the right idea, with their 'homegrown build system' in a different repo than the plugin itself: https://github.com/mattn/vim-lsp-settings
@lifranc Nothing you've said so far has been anything near a "tip" because that would imply constructive criticism. Considering that repository was created after nvim-lsp, I'm guessing it was inspired by this one. And the "homegrown build system" is entirely optional as is nvim-lsp itself. The built-in neovim lsp is what is required, and is already complete. This repository is exactly like the vim-lsp-settings crate.
Considering you are using nix, of course the build system added for convenience might not work. If it doesn't, then that's because you are an exception, and you can come up with your own solution and make a PR here.
From the outset your tone has been condescending and unhelpful. If you want to continue commenting on this thread, then I would appreciate it if you give more constructive advice and further context, because currently this doesn't qualify as an actual issue considering no real problem or question was stated.
Any plugin that tries to mkdir when loading is trying to be a build system
@lifranc No, this is simply just false. The directory it tries to create is just $HOME (likely because it needs to mkdir -p a cache dir beneath it). _A lot_ of software assumes it can store cache and config beneath $HOME (or better explicitly the XDG config vars), all these programs are not build systems.
Dont talk to me like im some fucking idiot
My point was just that you cannot derive _intentions_ (be a build system) from potentially incorrect/buggy behavior (unexpectedly create a dir). But now we know it is just HOME which is not buggy.
The only thing which could be seen as a "build system" in this repo would be :LspInstall which entirely optional code which does nothing unless invoked by the user. And as @norcalli said, this is already split up like https://github.com/mattn/vim-lsp-settings is from the client itself (which is part of neovim core repo).
@mjlbach What is the reason that nix tries to load neovim plugins at all during nix-build ? Is this some kind of sanity check that the plugin is working? Does nix packages in general try to run the software as part of the packaging process (even if there is no explicit "test" make target)?
Any plugin that tries to mkdir when loading is trying to be a build system
We could at least make it more lazy, it's unlikely we need to do this at load-time.
I am guessing this is the offending code:
We could be a bit more lazy. But if we need to write to a log, where should it go? Is creating files also verboten? (Why or why not?) We are trying to log to XDG data directory. AFAIK the XDG spec intends for programs to create directories in there (not only "build systems").
What's nixos expectation there?
Loading the plugins is past the build phase. Forget about nix, my point is; separate your build phase from your runtime phase, which, in my world means spinning up another git (I have gits with a dozen LoC). If you want to create a daemon (write a log), that's different from a vim plugin.
My context, for those interested: Im putting together a nixos fork which goes for complete purity. Essentially, writing to the file system will be limited to working in git repos and the like. Sorry if I came out abrasive, but there's a lot of code going against my goals, which are correctness, and it gets frustrating to find (what I consider) build scripts hidden in all kinds of places. So, yes. in my view mkdir == build system
@mjlbach What is the reason that nix tries to load neovim plugins at all during
nix-build
AFAIK the XDG spec intends for programs to create directories in there
You're right, but my goal is to do a lot better than that. Right now, any new process could write in places it has no business writing into. That's incorrect. Correctness, and not specs, is the better guide. The lua VM can hold state, so why not put all your lua code's state right there? Persistent state is a build-phase thing, so any changes there basically consist in rebuilding.
Correctness can only be total, or nil. Correctness of the entire system can only be deduced by analysing it in its entirety.
I am guessing this is the offending code:
This is quite insane. Nvim now has an embedded daemon. Sigh ... Im closing, cause some ships arent worth saving. Going back to vim-lsp after learning yet another pointless pseudo-programming language to fix more insane, untyped and barely readable stuff. Millions of programmers and yet not a single real programming framework in existence today. Keep writing more obsolete stuff, and keep booing those who point out the pointlessness of your work. Facts are rarely comforting so keep clear of them. This is my last github exchange. Consider yourselves the lucky last ones.
I'm sorry for the tone in this issue, it doesn't reflect the usually very nice nix community. Just to clarify the underlying issue: Nix allows users to build a pre-configured neovim. This configuration includes plugins. During the build phase, it will execute neovim with plugins enabled to generate the remote plugin manifest. Since builds happen in a sandbox, there is no home dir and the $HOME variable defaults to the non-existing /homeless-shelter.
I would argue that creating files & folders when simply loading a plugin should be avoided. Its not a big deal though, we can work around it on our end by just setting $HOME to a temporary directory and ignoring whatever the plugins write there.
Thanks for taking this issue seriously, despite the tone.
A patch to neovim core that makes the logging optional when it can't create the file would probably be fine too, correct?
We can take this line:
vim.fn.mkdir(vim.fn.stdpath('data'), "p")
and if it fails, simply make all the logging no-ops with a warning message printed w/in nvim or similar.
and no worries @timokau :smile:
Yes, that probably wouldn't be a bad idea. We might end up just setting HOME anyway though to work around similar problems in other plugins.
Most helpful comment
@lifranc Nothing you've said so far has been anything near a "tip" because that would imply constructive criticism. Considering that repository was created after nvim-lsp, I'm guessing it was inspired by this one. And the "homegrown build system" is entirely optional as is
nvim-lspitself. The built-in neovim lsp is what is required, and is already complete. This repository is exactly like the vim-lsp-settings crate.Considering you are using nix, of course the build system added for convenience might not work. If it doesn't, then that's because you are an exception, and you can come up with your own solution and make a PR here.
From the outset your tone has been condescending and unhelpful. If you want to continue commenting on this thread, then I would appreciate it if you give more constructive advice and further context, because currently this doesn't qualify as an actual issue considering no real problem or question was stated.