Linter doesn't check `LOAD_PATH` for packages

[ssfrr]

The linter seems to think things are undefined even if they are there:

Defined here:

used here:

output in the linter pane:

I think this might have to do with the fact that the SampledSignals package isn't located in the normal .julia/v0.6 package directory, but is in a different directory that I add to my LOAD_PATH in .juliarc.jl.

It also might be more useful in this case to display the warning on the import line with something like "Could not find package SampledSignals" rather than later on when you try to use the identifier.

[davidanthoff]

Yes, we certainly don't handle those cases.

[KristofferC]

IIUC, the way vscode does it right now is to actually load the packages to find out their symbols. Shouldn't it be enough to just load the .juliarc.jl file in the vscode julia process so that LOAD_PATH is updated and the packages can be loaded?

[davidanthoff]

Yeah, that would work, but we really need to move away from this model where the LS process loads user code. And executing .juliarc.jl to me seems even more risky than just loading the packages, who knows what users have in that file...

[KristofferC]

Well, typically stuff that should be OK to execute when you start julia...?

[ssfrr]

Another option would be to add an explicit LOAD_PATH-type option to the configuration, so users can specify other places they keep packages. On the other hand it might not be worth fiddling with until Pkg3 comes out, which I imagine will change this sort of thing substantially

[ufechner7]

Any updates on this issue? Any idea for a hack to make it work for now?

[davidanthoff]

No update, I'm afraid.

[ufechner7]

Pkg3 is out and alive, so there should be a way to solve this issue permanently now. I tried to add my package path to ~/.vscode/extensions/julialang.language-julia-0.11.1/scripts/languageserver
and here to the file main.jl

    ...
    empty!(LOAD_PATH)
    push!(LOAD_PATH, joinpath(@__DIR__, "packages"))
    push!(LOAD_PATH, "@stdlib")
    push!(LOAD_PATH, "/home/ufechner/copter-control/scripts")
    
    using LanguageServer, Sockets, SymbolServer
    ...

This used to work before, but doesn't have any effect with version 0.11.1 :(

Pkg3 now provides dev for this kind of usage and
I've figured that stop using push!(LOAD_PATH, "mypath") and start using pkg>dev mypath solved all my headaches 😄

Linter cheks for packages registerd with pkg>dev.

[twadleigh]

bump

I'm in a situation where I can't make my packages individual repos---they live in a subdirectory of a monorepo of mostly C++---and have to rely on modifying LOAD_PATH in startup.jl.

I'm looking for the right point to hack something into LanguageServer.jl, etc., but haven't found it yet.

[davidanthoff]

I think roughly the strategy would be that we pass the content of JULIA_LOAD_PATH env variable "through" the LS process to the symbol server process. In particular, we want the LS process to run with an empty JULIA_LOAD_PATH, but we then want the symbol server process to run with the content of that env variable.

So I think the steps would be to add another arg to the LS process startup around here, similar to oldDepotPath, for the content of JULIA_LOAD_PATH. Then we should probably also make sure that we run the LS server with an empty JULIA_LOAD_PATH here (that is kind of a bug right now, we should actually clear JULIA_LOAD_PATH for the LS process no matter what). Then, when we start the symbol server process here we would set the JULIA_LOAD_PATH env var again for that sub process. That should be feasible from the LS process because we now received the value for that as a command line arg.

Let me know if this explanation is too brief, happy to expand. What this would do is have the LS broadly pick up the content of JULIA_LOAD_PATH. I think that is pretty much the only thing we can do in this situation?

Or we could run startup.jl for the symbol server process, but I'm kind of nervous about that, given that there might be stuff in there that can be funky...

I think in any case we should probably do this in the v0.13.0 cycle, my hope is that we can get v0.12.0 out before juliacon, and this seems like a too big change to me to still do right now.

[ufechner7]

I would already be happy if I could hardcode my load path somewhere. So you mean adding env_to_use["JULIA_LOAD_PATH"] = "/home/ufechner/copter-control/scripts" after line 31 of SymbolServer.jl might work for me?