Warn if pyright is started from $HOME

[hejops]

Language server

pyright

Requested feature

The behaviour of lspconfig.util.root_pattern is "depth-first":

nvim-lspconfig/lua/lspconfig/util.lua

Lines 251 to 262 in 7eed8b2

	function M.root_pattern(...)
	local patterns = vim.tbl_flatten { ... }
	return function(startpath)
	startpath = M.strip_archive_subpath(startpath)
	for _, pattern in ipairs(patterns) do
	local match = M.search_ancestors(startpath, function(path)
	for _, p in ipairs(vim.fn.glob(M.path.join(M.path.escape_wildcards(path), pattern), true, true)) do
	if M.path.exists(p) then
	return path
	end
	end
	end)

i.e., it checks the existence of a given root_file (e.g. pyproject.toml in the current working dir), ascends as far up if it can, then tries the next root_file in the current working dir.

As a result, the existence of a hypothetical ~/pyproject.toml (which, in real world situations, should probably not exist):

~/pyproject.toml
~/project/.git
~/project/file1
~/project/pyrightconfig.json
~/project/subproject/.git
~/project/subproject/file2

would override any other root_file. Since pyright has no problems with being initiated from $HOME, it will go on ahead, but take a very long time to init (up to 2 minutes on a convoluted macos system). A warning is produced in LspLog, but otherwise, the user has no idea that something might be off.

Short of reworking root_pattern to allow breadth-first search (which is, in itself, undesirable, since in the above example, setting the project root to be ~/project when working on file2 is fairly sane behaviour), the minimum change would be to raise a warning if pyright is being started from $HOME. In most foreseeable cases, users will not have any of the following files in $HOME.

nvim-lspconfig/lua/lspconfig/server_configurations/pyright.lua

Lines 3 to 11 in 7eed8b2

	local root_files = {
	'pyproject.toml',
	'setup.py',
	'setup.cfg',
	'requirements.txt',
	'Pipfile',
	'pyrightconfig.json',
	'.git',
	}

The only notable exception is $HOME/.git for dotfiles containing python files. Such situations are not unheard of, so I'm not sure if the warning would be useful.

NB: I saw that root_pattern has been slated for deprecation (since 2022-08 -- #2079), but I haven't looked at the corresponding vim.fs equivalent.

Other clients which have this feature

No response

[ouuan]

It's #2885 that "cleaned" some configurations (#2904), but broke many others like #2975 and this one. It also broke my setup because I have a .eslintrc.js in $HOME and .eslintrc.cjs in my project.

I suggest that #2885 should be reimplemented in a backward-compatible way that does not change the behavior of the old configurations. e.g. use a new function or argument for the new behavior.

[justinmk]

the existence of a hypothetical ~/pyproject.toml (which, in real world situations, should probably not exist):

And if it does exist, then the behavior is correct.

#2885 changed the behavior to be more deterministic and avoid lots of hand written code in the configs.

It also broke my setup because I have a .eslintrc.js in $HOME and .eslintrc.cjs in my project.

If you have an eslintrc in your HOME then presumably your HOME is a eslint project.

[ouuan]

The problem is that, almost all configurations were not using root_pattern(pattern1) or root_pattern(pattern2) or root_pattern(pattern3). They were using root_pattern(pattern1, pattern2, pattern3) or root_pattern(pattern1, pattern2) or root_pattern(pattern3, pattern4). So #2885 is not just a clean-up, but rather changes the behavior of most of them. Are you sure the new behavior is desired in all these servers? e.g. I'm sure that prioritizing eslintrc.js over eslintrc.cjs is incorrect.

[ouuan]

I think we should be able to specify that several patterns are of the same priority.

[ouuan]

If you have an eslintrc in your HOME then presumably your HOME is a eslint project.

1. The actually correct behavior is to check for the root option in eslintrc, and stop at root: true. But that's complicated and it's acceptable to just approach the correct behavior in most situations.
2. Let's just assume that what you say is correct. Then it's still irrelevant to prioritizing some eslintrc file formats. What if eslintrc.cjs is at $HOME and eslintrc.js is in my project?

#2885 changed the behavior to be more deterministic

Guessing which file format is prioritized is non-deterministic for me.