Use juliaup to install julia

[IanButterworth]

Theoretically using juliaup could make things a lot simpler and easier to maintain.

[DilumAluthge]

IMO, this action (setup-julia) works very well as-is without Juliaup. And I think that adding Juliaup as a dependency brings a whole lot of extra complexity.

I think that we should leave this action (setup-julia) alone, and instead maintain a separate action for those people that want to use Juliaup in CI.

I've created such an action here: https://github.com/julia-actions/install-juliaup. The core functionality is now working in that action, so it's ready for people to try out.

[KristofferC]

And I think that adding Juliaup as a dependency brings a whole lot of extra complexity.

What are the "whole lot of extra complexity" here? Juliaup has features that are nice to use from here, like LTS, prerelease support, arch detection etc. It is also how we expect most users to install julia so replicating that in CI is a good thing. It also means we don't have to replicate code like #234.

I think that we should leave this action (setup-julia) alone, and instead maintain a separate action for those people that want to use Juliaup in CI.

No one "want to use Juliaup in CI", they just want julia installed. Having a bunch of different actions for the exact installation process of Julia seems pretty worthless. If there are worries about small changes here causing unexpected effects downstream then this repo can be deprecated in favour of the juliaup one? But maintaining two separate ones seem like endless headaches.

[davidanthoff]

I would prefer that we just make a new major release here if the migration introduces a breaking change (well, it will). In general I think we should not market Juliaup as an alternative install option, we should really just brand things as "this is how you install Julia". So I think the name Juliaup shouldn't even appear in the action name.

[IanButterworth]

What are the necessary unavoidable breaking changes?

[davidanthoff]

Minimally the string that selects a Julia version will have different semantics... Ideally, we would call it channel, to match the Juliaup terminology. I guess we could potentially keep julia-version as a deprecated option around and manually try to translate that into the corresponding Juliaup channel name... Similar thing is true for the arch input, I guess. In Juliaup land we would just make that part of the channel selector.