julia support should probably use modern julia multiplexing tooling (juliaup)

[haberdashPI]

Hi, I just ran across this project and thought it looked really great. So far I've really appreciated what I've seen. Thanks so much!

The experience with asdf and julia is subpar compared to the julia-specific version multiplexer (juliaup); that tends to be more up-to-date and stable (and is getting support from the language itself at this point, if I understand correctly).

What would it take to have mise make use of juliaup instead of the asdf plugin for julia?

[jdx]

I suppose my first question is what do you mean to "have mise make use of juliaup". Given juliaup itself if a version manager, I could see 3 things this could mean:

• mise interacts with juliaup similarly to rustup where it by default still uses standard paths like ~/.rustup and ~/.cargo, just sets RUST_TOOLCHAIN to dictate to rustup which version to use
• mise (in a core tool, vfox, or asdf plugin), calls juliaup just for installing versions like kerl in erlang or python with python-build but otherwise doesn't use the version manager capabilities
• we just add juliaup to the mise registry so you can install it with mise but then manage julia installs through juliaup directly—this is likely trivial if you can install it with aqua or ubi

I have no real preference here, I think they all work, but in some cases (like rust) the idiomatics of that ecosystem meant that we do things differently there. We should do what is idiomatic in julia but that's a language I know absolutely nothing about.

Julia is popular enough that if someone were to build a core tool for it I would be happy to maintain it from then on but not popular enough that I would consider building it myself right now. If you wanted to have a stab at that, the other core tools are a great reference: https://github.com/jdx/mise/tree/main/src/plugins/core

[haberdashPI]

As only a user of juliaup and only recently introduced to mise, I don't feel super qualified to say which of those is the best path forward but my guess would be "mise interacts with juliaup similarly to rustup"

What I do know is that juliaup is usually installed via a shell command.

curl -fsSL https://install.julialang.org | sh

And then one requests to install a given julia version via it's name (e.g. juliaup install release). juliaup creates a shim binary for julia and one can select specific versions of julia by calling julia with a special initial argument: julia +[version]. (There are ways to change the default globally and for a given path). In the case of julia, startup times are fairly long and so one doesn't really care about the cost of calling said shim: if startup times where a major concern you'd either be using a different language (even juliaup uses rust!) or the bleeding edge juliac to generate a standalone binary.

Knowing little of the internals of mise it seems like the simplest approach would be to have mise run the shell command for juliaup and, using the information for the active mise configuration, run julia with the appropriate version by calling julia +[version].

Perhaps some of the maintainers of juliaup can comment on this? @davidanthoff?

[haberdashPI]

As I'm understanding and learning more about mise, a simpler and relatively ergonomic solution seems possible:

• Register juliaup with mise. (It looks to me like the releases available on juliaup's github release page are compatible with ubi, I'll try it out).

• During development, rather than calling the julia binary directly, use a mise task that can run a specific version of julia installed via juliaup.

So that is really your proposed option 3 above.

[haberdashPI]

And further reading / investigation has taken me towards what I hope is an even simpler route:

The features for juliaup are mostly replications of the more generic setup in mise / aqua. It now looks like I should be able to add julia to the registry for aqua directly (and it looks like aqua's tests will test that what I do setup works across platforms).