[julia]: Better configurability for LanguageServer.jl install location. #1153
Conversation
fredrikekre
force-pushed
the
fe/julia-v2
branch
2 times, most recently
from
4995d0b
to
3eb4b93
Compare
|
Should we just set the current hardcoded cmd to what is recommended in the installation instructions in this PR? Is there a reason a user would ever prefer a global installation of LanguageServer.jl? That would simplify things. We might also include instructions for compiling a system image wtih PackageCompiler.jl |
|
If you are okay with that then I believe that is "best practice" since the language server process is an isolated thing and it is good to have an isolated package environment for it. |
|
I think it's way easier than suggesting these overrides, and we're already providing installation instructions so why not follow best practice? |
fredrikekre
force-pushed
the
fe/julia-v2
branch
from
3eb4b93
to
bf2f76e
Compare
fredrikekre
force-pushed
the
fe/julia-v2
branch
from
bf2f76e
to
f5f59b8
Compare
| ```sh | ||
| julia -e 'using Pkg; Pkg.add("LanguageServer"); Pkg.add("SymbolServer")' | ||
| julia --project=~/.julia/environments/nvim-lspconfig -e 'using Pkg; Pkg.add("LanguageServer")' |
There was a problem hiding this comment.
In Julia 1.7 and above this can be spelled
julia --project=@nvim-lspconfig -e 'using Pkg; Pkg.add("LanguageServer")'
but lets wait (at least) until that is released before recommending that.
| # Load LanguageServer.jl: attempt to load from ~/.julia/environments/nvim-lspconfig | ||
| # with the regular load path as a fallback | ||
| ls_install_path = joinpath( | ||
| get(DEPOT_PATH, 1, joinpath(homedir(), ".julia")), | ||
| "environments", "nvim-lspconfig" | ||
| ) | ||
| pushfirst!(LOAD_PATH, ls_install_path) | ||
| using LanguageServer | ||
| popfirst!(LOAD_PATH) |
There was a problem hiding this comment.
Why do we still need all of this if we are passing --project to the julia process? Is this preferable?
There was a problem hiding this comment.
We are not passing --project actually. It is a bit tricky, because that would interfere with the project discovery on the lines after. I think the only options are the PR as is, or to juggle with Base.ACTIVE_PROJECT[] instead in an equally "hacky" way.
There was a problem hiding this comment.
Sorry, I meant to imply "why shouldn't we just pass --project?"
I think I understand now, Base.active_project() would then return the project.toml containing directory for LanguageServer.jl vs the one containing the project meant to be analyzed/passed to the LanguageServer.jl instance.
For now, this is good. I still think there's a little bit of duplication in functionality between our root detection in lspconfig and the project.toml detection for figuring out the appropriate julia environment.
|
@fredrikekre is this ready now? |
|
Yes. It shouldn't (:crossed_fingers:) break for anyone since the config still fall backs to the global env. Only difference should be that we look in |
I think after this patch, no user configuration is necessary unless you want to have LanguageServer.jl installed into a custom package environment.