Add alias command

[christiangnrd]

Many implementation decisions were made. I'm open to suggestions/improvements/bikeshedding.

Close #838
Close #830

[StefanKarpinski]

Seems good to me (very naively). Could we get a rebase and a review?

[StefanKarpinski]

Bump. @davidanthoff, could you have a look at this or suggest someone else who could review?

[StefanKarpinski]

@IanButterworth, you've got some Rust chops. Could you review this and merge if it looks good?

[IanButterworth]

I got Claude to help a review and found a few issues that I tested and fixed in #1235

• Typo b08988b
• No circular alias detection/protection fa1288b
• Not showing aliases in list faee75f
• Tests 4fecee6

I would set the merge base of that PR to this one, but your branch is on a fork so I can't do that.

@christiangnrd let me know what you think of #1235. I can push them here if you agree.

Otherwise this is looking good to me.

[christiangnrd]

@IanButterworth Aside from the two comments I made in #1235, the rest looks great. Feel free to push here.

Thank you for taking the time to review this!

[MilesCranmer]

Actually wait. Before merging a hand rolled version, does rustup have something new for this we could pull? The more updated we can be with upstream the better in my view.

[MilesCranmer]

Looks like rustup added a similar feature upstream called a "toolchain override shorthand"
https://rust-lang.github.io/rustup/overrides.html#toolchain-override-shorthand

I feel like it would be better to merge features from upstream rather than recreate them from scratch

[IanButterworth]

I'm not familiar with rustup but that doesn't seem equivalent? It doesn't seem to provide a way to alias a channel (or toolchain) just shows ways to use different standard toolchains, which is what juliaup already provides.

Aliasing channels seems different?

[christiangnrd]

Looks like rustup added a similar feature upstream called a "toolchain override shorthand" https://rust-lang.github.io/rustup/overrides.html#toolchain-override-shorthand

I feel like it would be better to merge features from upstream rather than recreate them from scratch

That seems to be the rustup toolchain link command in rustup, which we also have as juliaup link. That's different as alias is linking a custom channel name to an existing channel, whereas link is linking a custom channel name to a specific Julia executable.

[MilesCranmer]

Sorry I confused myself that juliaup isn't a literal fork of rustup, it was just heavily inspired in its design. So we can't "merge" features per se from "upstream"

But given the similarities in designs, I think it would be good to stay close to rustup's design choices unless there's a strong reason not to for something.

A rustup "toolchain" is analogous to a juliaup "channel." A rustup "override" means simply passing a +toolchain to the cargo call, overriding the one set by rustup default. So in juliaup if I were to have juliaup default 1.11 then a julia +1.12 ... would be a channel "override".

So a "toolchain override shorthand" sounds like an alias (though I don't see much in the form of docs on that page?). Anyways I think it would be good for us to look at that design first before settling on a design from scratch here

[MilesCranmer]

Ah, I'm being an idiot, a "shorthand" on that page literally just means the +.

Time for bed...

[IanButterworth]

I think that's all a different thing.

This just making it so you can shorthand.

So instead of

julia +release
julia +nightly

you can

julia +r
julia +n

[MilesCranmer]

Oh I see. What's the advantage over alias juliar="julia +release"?

I guess I could see a use if #1230 merges, then you could use the alias in different contexts?

[IanButterworth]

Just pushed a tweak to messaging when removing an alias

Was

% ./target/debug/juliaup rm r           
Deleting symlink julia-r.
Nothing to remove.
Julia 'r' successfully removed.

Now

% ./target/debug/juliaup rm r
Deleting symlink julia-r.
Nothing to remove.
Alias 'r' (pointing to 'release') successfully removed.

[christiangnrd]

Just pushed a tweak to messaging when removing an alias

I like this. Should custom channels from juliaup link also get a custom message with the directory they pointed to?

Kind of unrelated:
I'm not a fan of the Nothing to remove from the line above. It comes from the GC (#1205), which indeed has no binaries to remove, but I find it very confusing when written without context.

Probably out of scope for this PR, since the behaviour existed before this PR (same thing happens when removing linked channels), but I think the "Nothing to remove" should be printed only when juliaup gc is explicitly called, or the message should provide more context.

I can open an issue from this comment if more discussion is needed.

[MilesCranmer]

Ok, looking at this with fresh eyes; apologies for the confusion earlier.

So, I may be missing something, but juliaup link seems to cover the alias use case:

juliaup link b ~/.julia/bin/julia-beta
# Creating shim julia-b for /Users/mcranmer/.julia/bin/julia-beta .

julia +b  # works fine

If the issue is usability, could we improve link (or its docs/UX) rather than add a very similar subcommand? Are there cases where an alias would enable something link cannot? Happy to be corrected. Just trying to converge on the most intuitive interface.

e.g., maybe

juliaup link b beta

rather than alias. But in this case I feel like its better to be explicit and have something like

juliaup link b --channel beta

Edit: I see @davidanthoff suggested something similar: #830 (comment)

juliaup link b +beta

which is also my preference

[IanButterworth]

juliaup link b +beta seems reasonable to me, if that has the strongest agreement.

[StefanKarpinski]

juliaup link b +beta seems fine, but creating an alias and linking a name to a custom binary are not really the same operation. But using the same verb for two similar actions is ok and certainly very Julian.

[IanButterworth]

@christiangnrd given this PR is old, I thought it might be easier for all to just start afresh with the switch to juliaup link r +release #1237

[IanButterworth]

I'm proposing we move forward with #1237

[christiangnrd]

Closing in favour of #1237