Enforce at least Julia 1.6 for the LS

[davidanthoff]

The logic is as follows:

• If Juliaup is installed it will always be used for the LS, no option for the user to opt-out of that. If the release channel is not installed, we error with a message saying that the release channel must be installed for the best Julia experience in VS Code. And then we just always use the release channel.
• If Juliaup is not installed, we check whether the configured Julia version is at least 1.6. If not, we error and point folks to the Julia homepage.
• If nothing is detected, we also no longer point folks to the exectuablePath setting, instead we just say "Julia needs to be installed" and point to julialang.org.

I think this is actually overall a much better experience for most users. Plus, it will make our life infinitely better because we can drop pre 1.6 compatibility in the LS.

@pfitzseb if this looks good to you, I will do some more commits that remove all the now unnecessary environments for old Julia versions for the LS. DONE

[pfitzseb]

Looks good. Thoughts on adding a setting for a LS specific Julia path?

[davidanthoff]

I thought about it, but maybe we try it without first and see whether that is good enough? I think we should generally try to reduce the complexity, and in this case it would really only affect folks that want to run pre 1.6 without Juliaup, and right now I'm thinking that doesn't warrant the extra complexity?

I'll merge this now, and then I will still have to make a change how symbol server is started, we need to add the option to start that with a different Julia version than the LS.

[jebej]

I just ran into this because I manually manage my julia versions and so didn't have the "release" channel installed, even though I had 1.10. Not sure why the LS absolutely needs the channel, can't it just use whatever latest compatible version is installed?

[davidanthoff]

In theory the implementation should be:

1. IF you have Juliaup installed, you must have the release channel installed and we will use that
2. If not Juliaup is found, then you must have at least Julia 1.6 installed.

So if I understand your scenario correctly, then it should work in theory. Are you getting an error message?

[jebej]

Yes, the LS was not starting. There was a message to go check the Julia LS Output, but there was no such tab in the panel. It was slightly confusing because the message about the release channel had already disappeared, so I was not sure why it was not working.

[jebej]

Ah I misread, yes I do have juliaup, but my point is that even with juliaup and without the release channel it should work.

[davidanthoff]

Ok, I'm very tempted to just leave as is. Everything else just adds a huge amount of complexity, and it doesn't strike me as cumbersome to just have the release channel installed.

I think the long-term solution here is to use the new juliac to compile the LS and ship that.

[jebej]

Are there any potential issues if the LS and the execution process are using different julia versions? I manually specify which julia binary I want in the settings, so as soon as the next julia version e.g. 1.11 is released that will occur.

[davidanthoff]

No, we decoupled that as part of this change. We plan to always support any Julia version starting at 1.0 for the code you run or edit etc. So while we now limit the versions of Julia that can run the actual language server, we do not enforce that for the child processes that we sometimes launch in order to extract symbol information etc, those will continue to run on the Julia version that the user uses, and those can be any version.

This change was really just done so that we can use Salsa.jl inside the LS, which only runs on newer Julia versions.