lspcontainers.nvim icon indicating copy to clipboard operation
lspcontainers.nvim copied to clipboard

custom gopls config error loading workspace folders

Open s0alqasim1d opened this issue 3 years ago • 3 comments

I am using a Windows setup with no WSL (docker does use WSL2 backend, but I'm not using WSL2 in the terminal). I want to run gopls in a container. I was able to get a couple of the other LSPs to work without issues like pyright, sumneko_lua, dockerls. I want to use gopls but I can't figure out the issue exactly. I got the container running after overriding cmd_builder with my own but I don't know what I'm missing. Can you take a look at my config?

local lspconfig = require("lspconfig")
local util = require("lspconfig.util")
local configs = require("lspconfig.configs")
local lspcontainers = require("lspcontainers")
local capabilities = require"plugins.autocompletion_capabilities" --returns capabilities

local servers = {
  gopls = {
        cmd_builder = function(runtime, root_dir, image, network)
	  local user = "gopls:gopls" --NOTE: or 1000:1001
	  local gopath = "/home/gopls/go"
	  local workdir= "/workspace/"
	  local cutils = require("plugins.cutils") -- contains Dos2UnixSafePath I copied from lspcontainers src.
	  local volumes = {
		  v1 = "--volume="..cutils.Dos2UnixSafePath(root_dir).."/:"..workdir, -- Also tried mounting to the same path inside the container as on the host like /c/Users/AlQasim/Desktop/go-json/
		  v2 = "--volume="..cutils.Dos2UnixSafePath(require("os").getenv("GOPATH"))..":".."/go:z",-- NOTE: Mounting my local gopath into container in a different directory & adding that to the container gopath later
	  }
	  return {
		  runtime,
		  "container",
		  "run",
		  "--rm",
		  "-i",
		  "-e GOPATH=/go:"..gopath,--NOTE: We add the mounted local GOPATH to the GOPATH variable on container
		  "--network="..network,
		  "-w"..workdir,
		  volumes.v1,
		  volumes.v2,
		  "--user="..user,
		  image,
		  "gopls"
	  }
  end,
  image = "lspcontainers/gopls",
  -- network = "bridge", -- Maybe If I'm missing a package i'll do something
  -- root_dir = vim.fn.getcwd(), -- actually equals this by default
  --ISSUE: What is on_new_config?
  default_config = {
	  cmd = {"gopls"},
	  filetypes = {"go", "gomod", "gotmpl"},
	  root_dir = util.root_pattern("go.work", "go.mod", ".git"), -- I think this is ignored 
	  -- root_dir = function(fname)
	  -- 	  return util.root_pattern 'go.work'(fname) or util.root_pattern('go.mod', '.git')(fname)
	  -- 	end,
	  single_file_support = true,
  },
  settings = {
	  gopls = {
	    verboseOutput = true,
	    analyses = {
			    unusedparams = true,
	    },
	    staticcheck = true,
    },
  },
...
},
...

for lsp, lsp_opts in pairs(servers) do
	-- print(lsp, lsp_opts.default_config and 1 or 2)
	--if not lspcontainers.supported_languages[lsp] then -- some custom server I added cannot find its config unless I did this
		--configs[lsp] = { default_config = lsp_opts.default_config}
		--lspcontainers.supported_languages[lsp] = lsp_opts.cmd
	--end
	lspconfig[lsp].setup {
		before_init = function(params)
			params.processId = vim.NIL
		end,
		cmd = lspcontainers.command(lsp, lsp_opts),
		root_dir = lsp_opts.default_config and lsp_opts.default_config.root_dir or configs[lsp].default_config or util.root_pattern(".git", vim.fn.getcwd()),
		on_attach = on_attach,
		flags = {},
		capabilities = capabilities,
		settings = lsp_opts.settings or {}
	}
end

So the container stays running and communicating but since no workspace is found it does nothing. upon launching it gives me the "Error loading workspace folders (expected 1, got 0) failed to load view for file:///<file_path>: err: chdir <file_path>: no such file or directory: stderr:". I tried opening a shell in the container & my directory is mounted correctly & all files are there. I don't know what I'm missing. image

It might be the way it says my filepath using the Windows style instead of Unix-safe path, but I'm not sure what to do.

Later invoking some LSPSaga gives back "gopls: 0: no views in session" which I assume is related to the gopls not correctly detecting my files. image

Is there anything you see is wrong in what I'm doing? If so, any suggestions? I'm not sure about my lua code all that much. Also I wrote this months ago & mostly forgot my process writing this. I began to work on a go project & this surfaced back so take my code with low expectations.

If you see no issue in my approach I'll try on gopls repo, cuz i'm not sure what I broke.

Edit: Any input is appreciated.

Edit2: So I tried booting up a live Linux usb on my machine and installed docker & put my nvim config there too to test my config.

I modified the code to not try to safe escape the paths (I was doing it for DOS paths) & ran it. It still complained that the path is not found, & I remembered that I was mapping into a "/workspace/" directory in the container so I changed it to map into exactly the same path as the host like "/home/linux/go/src/go-practice/" then all worked fine.

So it does seem to need the same path as is sent by nvim-lsp (or anyways, the path that it's receiving from outside the container which it looks for inside).

Any ideas?

s0alqasim1d avatar Sep 17 '22 08:09 s0alqasim1d

I think maybe the next step is to attempt to play with the nvim api for lsp to try to change the URI sent to the container. I would be grateful for any feedback on this issue.

s0alqasim1d avatar Sep 25 '22 05:09 s0alqasim1d

Thank you for the information! Looking at your problem - I have no easy way to reproduce with regards to the technical requirements you have.

Thinking about your problem however with my limited experience with WSL - there will MOST likely need to be support in lspcontainers to handle paths when inside and when not. The reason for that is because WSL nests your C:\ and other drives to a dedicated path. Also it uses the 777 permissions to modify files which is not great.

I am currently in the process of creating a proposal for changes in the next version of LSPContainers and I think this is one we need to consider. I'm going to include this PR in the proposal AND leave it open so we can continue working on both.

erikreinert avatar Nov 07 '22 20:11 erikreinert

To be included in #92

erikreinert avatar Nov 07 '22 20:11 erikreinert