-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't require env_path
to be passed to LanguageServerInstance
#748
Comments
We'll have to rethink the whole env handling story very soon in any case, for example to support situations where there are multiple env in a given workspace folder. Having said that, I'm really not keen to support anything where the LS starts to look at files outside of the workspace that it is given by the client to work on. We do this with We have the same situation in VS Code: if you start |
I thought the purpose of At least I also think it is a bad choice to specify the |
Thanks for the quick response on this! I think the current interface where LanguageServer.jl is passed in the environment is simple and clean, and not implementing something that recursively searches for Project.toml files would be nice. I mainly wanted to open an issue to track this, since now that Neovim mostly works with LanguageServer.jl I expect more people will report similar issues :) In eglot-jl the following is used:
I'll look into get something similar working for neovim as well. |
It turns out |
The spec also has the following that is sent as part of the first request from the client to the server:
Is there a reason this can't be used to get the project path? |
@jwortmann I think I agree with everything you wrote, that makes much more sense than how I was thinking about this so far. The depot is a bit of a different case: that option is really just there so that the VS Code extension can do some of the insulating of the LS process from anything else, I think it falls under the category that "arguments which never change" you mentioned. But I fully agree on the env: we should probably just try to migrate that a normal configuration setting. We do have some errors related to the configuration story in our crash reporting, and I would want to fix those before we "task" the configuration stuff with more duties. If we think that the julia env will become a standard configuration setting, then I think we will have to insist that it will be a valid path to a valid julia env. If the config setting is empty, I could see the LS looking for environments in the workspace folders. |
Hey guys, I might be a little late to the game here, but I'm trying to figure this out and I think I'm missing a major point: Does LS need a My suggestion would be that, by default, LanguageServer do the following to check for the environment with the following priorities:
If any of the above locations contains multiple environments in the same directory when checked, give up, warn user (I don't see why anyone would do that anyway). If the Of course, this is all complicated by the fact that, as far as I can tell, the language server protocol doesn't seem to specify anything outside of pure language analysis, so there don't seem to be any standards whatsoever regarding how a client should communicate this sort of metadata to a server, how the server should report issues to the client etc. One of the infuriating consequences of this has been that none of the clients seem to have a way of reporting back to the user any warnings or information thrown by the langauge server, so things like which environment is being used is effectively hidden from the user, and we are dependent on the good graces of the maintainer of the particular client to provide that information. I believe this lack of standardization of anything outside of the core language analysis tasks is the main reason why using LSP has proved so very painful anywhere outside of the VScode context this package was designed for. However, because of this same problem, I think we are going to need LanguageServer.jl to do at least a little bit of work to try to figure out what environment it should be looking at, hopefully just the simple list above. Otherwise it will very easily break because it will be too reliant on a million separate language client implementations to always get it right. |
We'll rework the whole env handling thing after Juliacon, but that will be a pretty long project. In general, the LS will work better than today if it doesn't have information from the client on what env should be used. We will support situations where you open a package that has a I do think that @jwortmann's suggestion from above to just use the configuration system to communicate environment choices in the client to the LS is exactly right, so right now I very much plan to move in that direction as well, going forward. Having said that: we are still very much in the design phase of much of this, and will not focus on this until after Juliacon. |
runserver will attempt to pick a reasonable environment to run the language server against. Closes julia-vscode#748. We still need to address running the language server against a project with no Manifest.
I've run into similar issues trying to seperate the language server environment from my project environment in kakoune. Just to add my 2 cents:
|
When using
LanguageServerInstance
inneovim
, the default configuration currently starts a process forLanguageServer.jl
in the current working directory:https://github.com/neovim/nvim-lsp/blob/94cce7448f34f172492d98ff6efe10986f73eb9e/lua/nvim_lsp/julials.lua#L14
When using vim / neovim, users are going to possibly going to do this:
This means that LanguageServer will be started in the
Package.jl/src/module1
folder instead of atPackage.jl
where theProject.toml
file is located.Additionally, one can imagine a Package.jl that has some tests that depend on external packages. In this case, Package.jl/tests/extras may contain a Project.toml file that specifies some dependencies for running
test1.jl
.LanguageServer.jl/SymbolServer.jl will fail to find references / lint correctly in this case.
Would it be possible to have
project_path
recursively search up from the path provided till it finds aProject.toml
?The text was updated successfully, but these errors were encountered: