The vscode plugin is taking the LOAD_PATH of packages not into account, therefore symbols in my own code are not found. I am trying to fix that, but need some help.
What I tried so far:
tried to edit the file “~/.vscode/extensions/julialang.language-julia-0.11.5/scripts/languageserver/main.jl”. Adding:
function LanguageServerInstance(pipe_in, pipe_out, debug_mode::Bool, env_path, depot_path, packages)
The last parameter is a dictionary. Is it correct that adding the name of a user module in this dictionary would help?
And what is the difference between packages and modules? I have files, that define a module and are in local directory, but this are nof full packages with all the subdirectories and special files. Does that matter?
As I said in another tread, this doesn’t work for me. I also do not HAVE my own packages, I only have my own modules. When I try your suggestion I get the following message in pkg> status:
→ [14ec9285] src v0.0.0 [`~/00PythonSoftware/FastSim/src`]
┌ Warning: Some packages (indicated with a red arrow) are not downloaded, use `instantiate` to instantiate the current environment
└ @ Pkg.Display /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/Pkg/src/Display.jl:194
And using “intantiate” as suggested doesn’t make any difference, either.
Perhaps make them projects then? It is a very lightweight procedure, basically a pkg> generate. You get extras like being able to activate the environment, easier CI, etc.
I don’t want to have projects for modules that I need only in one program. That’s too much overhead. This are just scripts that are helpers for projects written in other languages in the first place, and they live in one folder. And I use modules to get the advantage of precompilation.
And I also asked something else:
The last parameter is a dictionary. Is it correct that adding the name of a user module in this dictionary would help?
So please help me to fix this issue and not only to find a workaround.
So here is the situation: the VS Code extension starts a new julia instance that is the language server. That code for that instance is scripts/languageserver/min.jl. We run that instance with a modified JULIA_DEPOT_PATH and a modified LOAD_PATH, and we shouldn’t change that. The reason they run with modified values there is to completely isolate the language server from anything that is going on in the users .julia folder, which has greatly helped us with setup and stability.
The language server process then starts another process, which we call the symbol server process. This process runs with JULIA_DEPOT_PATH pointing to the users .julia folder. In that process we load the packages that the user uses and extract all the information we need for the language server.
So broadly speaking what we would need to do is make sure that the symbol server process runs with the LOAD_PATH that @ufechner7 customized. One question: how did you customize the LOAD_PATH? By setting the env var JULIA_LOAD_PATH? Or just in your julia code?
Hm, that is going to be tricky… You are essentially dynamically changing the LOAD_PATH, and the whole concept of the language server is that of a static analysis… If you changed LOAD_PATH via the env var JULIA_LOAD_PATH I could maybe see a scenario where we propagate the content of that env var down to the symbol server process.
It used to work in an old version of the plugin, but it doesn’t work any more. @davidanthoff is the only person who knows how to fix that, but he is short of time.
Thanks, I tried push! on both .julia/config/startup.jl and the main.jl in the package, both doesn’t work. So I guess the Linter does not read LOAD_PATH…
anyway thanks for the great work and I will wait for the next version
