Change:
youcompleteme = super.youcompleteme.overrideAttrs(old: { buildPhase = '' substituteInPlace plugin/youcompleteme.vim  <del> --replace "'ycm_path_to_python_interpreter', '''"  "'ycm_path_to_python_interpreter', '${python}/bin/python'" </del> <ins> --replace "'ycm_python_interpreter_path', '''"  "'ycm_python_interpreter_path', '${python3}/bin/python'" </ins> rm -r third_party/ycmd ln -s ${ycmd}/lib/ycmd third_party ''; <del> meta = { </del> <ins> meta = with stdenv.lib; { </ins> description = "A code-completion engine for Vim"; <del> homepage = https://github.com/Valloric/YouCompleteMe; license = stdenv.lib.licenses.gpl3; maintainers = with stdenv.lib.maintainers; [marcweber jagajaga]; platforms = stdenv.lib.platforms.unix; </del> <ins> homepage = "https://github.com/Valloric/YouCompleteMe"; license = licenses.gpl3; maintainers = with maintainers; [ marcweber jagajaga ]; platforms = platforms.unix; </ins> }; });

Discussion:
Here's an of where the YouCompleteMe plugin (running python3 as the plugin host in , presumably; see trace below) attempts to start the server (a python2 program): It would seem that the neovim package does something such that when a python3 neovim plugin starts a python2 program, the python2 program's idea of is set to the environment created for the remote plugin host. This can be confirmed running this in : That will print the path from above. Note that the ycm plugin complains about the server shutting down. Look through the traces to see the aforementioned "ImportError: No module named site" message. system: host os: multi-user?: sandbox: version: channels(root): channels(cstrahan): nixpkgs:
There are a couple resolutions that come to mind: Build with python3, so that the works... though only if the executable uses the exact same version of python3 as the plugin host, and that may not necessarily be the case. Patch to unset the environment variable before starting . That would fix this case, but that does nothing to solve the general case of a nvim python plugin executing a python script with another python interpreter.
I would like to update the ycmd nix expression, they don't really do releases, so I'm not sure what point would be a good point to do a checkout. For now, that PR should resolve this issue.
This still has some remaining issues. When opening a python source file, the following message is printed: (I'm on Ubuntu right now, so I'm fairly sure a python2.7 from the store would have been resolved if I were on NixOS; I think that can be ignored as an orthogonal issue for this report) 's support for python code completion will still spawn a python2.7 interpreter, which will then crash due to pointing at a python3 prefix. Here's where figures out which python to use: See also: I think an easy fix will be patching YouCompleteMe to remove the environment variable before launching . Again, other plugins and neovim scripts will be subject to similar issues whenever the plugin host launches a python interpreter that doesn't match.

Maybe a reasonable solution would be to somehow monkey patch the python subprocess apis in the two python plugin hosts so that any spawned subprocesses don't inherit the plugin environment (the odds that they would utilize any of the packages would seem slim to me). Maybe that would fix more than it would break.
Removing the environment variable (and perhaps restoring it after) here should do the trick:
It would be nice if there was a vs a (or really, it would be nice if we could all just move to python3 and scrub any mention of python2 from existence, but I suppose that's being unreasonable). Given this class of defect is bound to be pervasive, we may want to consider carrying patches to our python interpreters such that they first look for , and failing that, look for after. I'm not convinced that's a perfect solution, but right now wherever we use a python environment via , we completely break any python subprocesses from the other major version. as maintainer of the CPython interpreters, what are your thoughts?
I'll take a look when i get home. I mean, , so if it's just compatible upgrades among the packages in the ycmd closure, then it shouldn't be too much of an issue. I was hoping that bumping the ycmd to python3 would be enough.
Leaking of is a problem. The solution is in my opinion It also uses an environment variable but then unsets it. Of course, this will break cases where subprocesses do need to invoke Python with these but instead point to the unwrapped versions. Wrapping sucks.
is now in staging.
in case it helps anyone, my current workaround is:
I marked this as stale due to inactivity. &rarr;
sounds like this was resolved, but this issue was forgotten.