Coc.nvim, nvim, stuff

I packaged the most basic version of coc.nvim in unstable.
You can autoinstall extensions via
let g:coc_global_extensions = ['coc-extension1', 'coc-extension2', 'coc-extension3', 'coc-extension4'] though it’s not nix-declarative.
I haven’t tried the coc-python extension much as it seems to be WIP, require .Net code etc.

Instead I’ve kept my pyls config
I’ve updated the coc.nvim wiki this week with a full example Language servers · neoclide/coc.nvim Wiki · GitHub .
Btw thanks for pushing me to install coc.nvim, it’s really awesome especially with neovim 0.4-dev and the floating windows).

you might also be interested in vimPlugins.coc: init at 19.02.2019 · Pull Request #56091 · NixOS/nixpkgs · GitHub

Hey, just wanted to share a small caveat I noticed when configuring jedi for coc-python.

vim-ghost’s python is Neovim’s python executable - python3_host_prog. But, coc-python’s python executable is the first python which is found in $PATH. Therefor, you need to use direenv or a similar workaround to use coc-python.

I use the following as a base .envrc for my Python projects:

use nix -p python37Packages.{jedi,pylint}

To be further accurate, I feel I need to note that @wizzup’s example which adds jedi to the extraPythonPackages doesn’t help coc-python at all, according to my tests.

I use the following in my ~/.config/nixpkgs/config.nix:

    neovim = pkgs.neovim.override {
      extraPython3Packages = (ps: with ps; [
        simple-websocket-server
        python-slugify
      ]);
    };

So this is kind of a cleaner way IMO to do the same thing.

It is good to know that you have a successful setup. Thank you for your investigation.

I have virtually zero knowledge on Nix’s python system and python run-time things.

Now I know something :smile:

1 Like

Having a lot of trouble getting my python setup up and running as well. It would be awesome if you could share your config.

This is what works for me.

Vanilla neovim installed globally.

Per project, a default.nix containing:

let 
  pkgs = import <nixpkgs> {}; 
in
with pkgs;
let 
  mypython = pkgs.python3;
  ppkgs = mypython.pkgs;
  
  # whatever package you need that's not alredy packaged
  docx2txt = with ppkgs; callPackage ~/src/nixpkgs/docx2txt {};
  
  my-packages = python-packages: with python-packages; 
  [
    docx2txt
    langid  # whatever python packages you need

    # stuff for coc.nvim
    jedi
    mypy pylama
    black isort
  ];
  python-stuff = mypython.withPackages (my-packages);
in mkShell {
  buildInputs = [
    python-stuff

    # stuff for coc.nvim
    nodejs yarn 
  ];
  shellHook = ''
    rm -f env
    ln -s ${python-stuff}/bin env
  '';
}

Finally, in CocConfig:

{
  "coc.preferences.formatOnSaveFiletypes": ["rust", "python"],

  "rust-client.channel": "stable",
  "rust-client.disableRustup": true,
  "rust-client.logToFile": true,

  "python.autoComplete.showAdvancedMembers": false,
  "python.pythonPath": "./env/python",
  "python.formatting.provider": "black",
  "python.formatting.blackPath": "./env/black",
  "python.linting.mypyEnabled": true,
  "python.linting.mypyPath": "./env/mypy",
  "python.linting.pylintEnabled": false,
  "python.linting.pylamaEnabled": true,
  "python.linting.pylamaPath": "./env/pylama",
  "python.sortImports.path": "./env/isort"
}

I don’t know how much of this is actually needed, and certainly I could refactor default.nix and extract a shell.nix, but it’s good enough for now.

2 Likes

Do you think trying to keep global python-tools (black, jedi, etc) is a bad idea? I want to avoid repetition in all environments.

Black should be fine, but jedi will probably not see the packages that you install only in the environment of the project, since it’s a different Python environment.

Haven’t tried, though.

And repetition can be factored out in a derivation that you call in all environments - but I still haven’t done it ^^

1 Like

Anyone have idea how I have 2 output channels with the following test shell.nix ?

{ pkgs ? import <nixpkgs> {} }:
with pkgs;

let
  neovim = pkgs.neovim.override {
    configure = {
      packages.myVimPackage = with pkgs.vimPlugins; {
        start = [ coc-nvim ];
        };
      };
  };

in
stdenv.mkDerivation {
  name = "hello";
  buildInputs = [
    neovim
  ] ++ (with python3Packages; [
    python-language-server
  ]);
}

you’re right… I should think about my setups as any other code, that’s what nix is for after all. If I want to DRY, there are other ways to DRY than singletons/globals.

I just create the issue for duplicated message and got shutdown immediately. :zipper_mouth_face:

Anyone know other alternative completion plugin for neovim i should try?

The issue was solved!

Source of the problem is somehow there is coc-pyls extension installed in ~/.config/coc.

I don’t remember how , maybe by :CocInstall command (impurely)

Not sure about which one is the prefer way to install a coc plugins between pure vs impure.

Any idea?

coc-pyls is deprecated, isn’t it ? so far I don’t think anyone can or is using the microsoft server declaratively.
I’ve kinda managed to package mpls/make it accessible:

but I haven’t found a way to tell coc-python to use it.
I’ve had some code to build coc from source too but didn’t have the time to test it and the current coc installer is quite straightforward.

1 Like

why doesn’t the downloaded mpls just work? Missing dotnet dependencies? I wasn’t able to make it work in non-declarative install either

EDIT 1: I was getting enoent and just learned about ldd :grimacing:. Time for some debugging

EDIT 2:
not sure why libstdc++.so.6 isn’t found, is it because it’s in a non standard location on nix? I have the gcc package installed

ldd Microsoft.Python.LanguageServer
        linux-vdso.so.1 (0x00007fff7d318000)
        libpthread.so.0 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libpthread.so.0 (0x00007fa74ac12000)
        libdl.so.2 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libdl.so.2 (0x00007fa74ac0d000)
        libstdc++.so.6 => not found
        libm.so.6 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libm.so.6 (0x00007fa74aa77000)
        libgcc_s.so.1 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libgcc_s.so.1 (0x00007fa74a861000)
        libc.so.6 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6 (0x00007fa74a6ab000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007fa74ac35000)

EDIT 3: Ok this makes it clearer Different methods to run a non-nixos executable on Nixos - Unix & Linux Stack Exchange

1 Like

Does anyone has a working example in the end?

1 Like

the python mpls server has been merged so it possible to install and use coc just for configuration. I personally switched to the builtin lsp since the lua ecosystem is more approachable for me than node (on nixpkgs).

Do you mean the builtin lsp of neovim or something else? I thought that was only available for neovim version 5.0? Did you build this version yourself? Was it a lot of work to build it successfully?

I would like to test out the embedded lsp server, as I find coc.vim a bit bloated and wasn’t able to make it work for all the things I need.

I was referring to the master version of nvim (called 0.5 but unreleased yet).

You should be fine with the following in your overlay

  neovim-unwrapped = final.neovim-unwrapped.overrideAttrs (oldAttrs: {
	  name = "neovim";
	  version = "official-master";
      src = builtins.fetchGit {
        url = https://github.com/neovim/neovim.git;
        ref = "master";
      };
 
  });
2 Likes

Hello!

I’ve just made a pull request to coc-python to make it use the python-language-server that’s in unstable nixpkgs right now.

https://github.com/neoclide/coc-python/pull/266

To use it right now, you can do

Plug 'irth/coc-python', {'branch': 'allow-changing-language-server-path', 'do': 'yarn install && yarn build'}

for vim-plug (or adapt that for your plugin management solution)

and then, in the coc-settings.json:

"python.autoUpdateLanguageServer": false,
"python.languageServerPath": "python-language-server"

Works like a charm :slight_smile:

3 Likes

Thanks for this code snippet regarding neovim nightly. Since I didn’t know much about overlays in nix I had to put it on hold, but now I finally was able to make it work. What I essentially did was to put this as my overlay.nix:

cat ~/.config/nixpkgs/overlays.nix

code:

[ (self: super:
{
  neovim-unwrapped = super.neovim-unwrapped.overrideAttrs (oldAttrs: rec {
    name = "neovim-nightly";
    version = "0.5-nightly";
    src = self.fetchurl {
      url = "https://github.com/neovim/neovim/archive/master.zip";
      sha256 = "01ad4sfavyhjaylzbqm0ynrngl38bkxai37yn16hryslk5rsb1jg";
    };

    nativeBuildInputs = with self.pkgs; [ unzip cmake pkgconfig gettext ];

  });

}) ]

then inside a clone of nixpkgs, I did nix-env -f "." -iA neovim, and it worked.

I think the nativeBuildInputs, could have been done like this:

nativeBuildInputs = with self.pkgs; [ unzip ] ++ super.nativeBuildInputs;

But then I get this failure:

error: attribute 'nativeBuildInputs' missing

I must say that overlays are really hard to get right and the documentation is a bit convoluted.

For anyone mastering overlays, it would be would nice to get feedback on this approach :slight_smile:

I guess that putting them at the system level like in this example is a better approach, maybe I’ll try that next:

1 Like