How to make vscode aware of user modules

question
#1

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:

  1. tried to edit the file “~/.vscode/extensions/julialang.language-julia-0.11.5/scripts/languageserver/main.jl”. Adding:
 push!(LOAD_PATH, "PATH_TO_MY_MODULES")

had now effect.
2. In the following file: https://github.com/JuliaEditorSupport/LanguageServer.jl/blob/master/src/languageserverinstance.jl a language server instance is defined. It can instantiated with:

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?

#2

This may not help you directly, but I have not been using LOAD_PATH for anything since v1.0. I just

pkg> dev path/to/pkg

my “local” packages (ie the ones I work on, may or may not be public).

#3

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.

#4

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.

#5

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.

#6

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?

#7

What is the difference between the JULIA_DEPOT_PATH and the LOAD_PATH?

Currently I custimize the LOAD_PATH in the following way:

push!(LOAD_PATH, pwd())

But doing it in a different way would not be a problem for me, as long as vscode finds the referenced modules, functions and variables.

And where in the code is the symbol server process started?

#8

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.

The symbol server gets started here.

I don’t think we would want to change anything about JULIA_DEPO_PATH in your case.