juliaup icon indicating copy to clipboard operation
juliaup copied to clipboard

running specific Julia versions

Open StefanKarpinski opened this issue 3 years ago • 7 comments

I may have missed it, but I couldn't figure out a way to run a specific Julia version without changing it to the default. It would also be handy to have an environment variable that controls the default Julia version so that something like direnv can set that environment variable and control what Julia binary gets used. Of course, direnv can always manipulate the PATH environment variable to control what julia resolves to, but it seems a bit cleaner to leave PATH alone, get juliaup's julia loader and have a separate way to tell it which Julia to use.

StefanKarpinski avatar Nov 29 '21 16:11 StefanKarpinski

The per invocation selection can be done with +CHANNELNAME: julia +1.3 for example. It has to be the first positional argument, that whole thing is essentially copied from rustup.

There is some outdated discussion of other aspects of this in https://github.com/JuliaLang/juliaup/issues/10. The main thing is that we just need to come up with a similar thing as https://rust-lang.github.io/rustup/overrides.html.

One thing that I'm not so sure about is whether the Julia version stored in Manifest.toml is enough as the directory specific selector, or whether we need another directory specific config file...

davidanthoff avatar Nov 29 '21 17:11 davidanthoff

Ah, I see — I missed the

(it can then be launched via the command julia +1.5.1)

note in the README. I have some design thoughts. Should I post then on #10 or here?

StefanKarpinski avatar Nov 29 '21 18:11 StefanKarpinski

Either place, doesn't really matter :) And admittedly that is very well hidden in the README ;)

davidanthoff avatar Nov 29 '21 18:11 davidanthoff

Instead of rolling our own configuration file, I think it would be nice if we could re-use a configuration file from another existing tool.

My proposal is to use .tool-versions: https://github.com/JuliaLang/juliaup/issues/181

The file format is relatively simple (https://asdf-vm.com/manage/configuration.html#tool-versions), and it would have the nice feature that juliaup would "interoperate" (albeit in a very simple way) with another tool.

DilumAluthge avatar Nov 30 '21 09:11 DilumAluthge

For Julia 1.7+, we can certainly try to read the julia_version from the Manifest.toml file. But for earlier Julia versions, the manifest files do not contain the Julia version. So I do think we still need some kind of directory-specific config file for specifying the Julia version. (Especially because Julia 1.6 is going to be the LTS for a while!)

DilumAluthge avatar Nov 30 '21 09:11 DilumAluthge

Yes, agreed that we need something additional. In particular because I think the version in Manifest.toml really is not a configuration value, but just a piece of information that tells a user what version was used to write that file. We also have the situation that in juliaup there is potentially a 1:n mapping between the kind of version recorded in a Manifest.toml and the available Julia versions on the local machine: users can e.g. have 1.7.0~x86 and 1.7.0~x64 installed at the same time, and we then need a way to configure which of those versions should be used.

So I think we probably want a new file for this, and probably the idea should be that it is a file that is not checked into version control, right?

davidanthoff avatar Dec 01 '21 17:12 davidanthoff

Would be nice to have julia +channel added to the help displayed for juliaup. Naively I assumed julia is just the julia executable, not a separate launcher with its own commands.

BioTurboNick avatar May 03 '22 13:05 BioTurboNick

PR #779 enhances the primary help text to explain about julia +channel at the end, hopefully more people see it there.

But this issue seems to be about more than that, namely also about a way to force a specific version of Julia to be run based on the current working directory?

fingolfin avatar Jan 05 '24 12:01 fingolfin

The JULIAUP_CHANNEL variable satisfies this need for me at this point. If we automatically look at the manifest in the future, all the better, but I'd say this issue can be closed now from my perspective.

StefanKarpinski avatar Jan 10 '24 18:01 StefanKarpinski