Support installing pre-built releases
tsloughter opened this issue · comments
We should start by pulling builds from https://github.com/wojtekmach/otp_releases/releases
The main question I have at this point is what command to use/create?
My initial thinking is we add a command erlup install <version>. The user can then use that instead of erlup build <tag> if they want to use a binary release. I sort of want install to also set the new version as the default, simply because install just sounds like it would do that -- of course with a --no-default option to not change the default.
But if install does update the default then there should also be a way to use it to build a tag and set it as default. I suppose it could be as simple as erlup install --tag <tag> will do a build and erlup install <version> will always do binary releases.
Oh and install should probably still support --repo to make it easy to test pointing at different repos for fetching the releases., esp since they'll eventually be moving to the erlang/otp repo.
Maybe we should try and first streamline the current interface and see where this would fit, i still get a bit confused with default/switch and build/fetch/report
The way i see it, people want to:
- build an Erlang from source, any repo that they choose, defaults to OTP's
- fetch a pre-compiled Erlang from somewhere, defaults to Wojteck's (or OTP's)
- switch around between any of the above
I envision the following:
erlup repo ls/add/rm --[source, binary]: adds source/binary repos with a given name, both default to OTP'serlup build <id> <repo>, builds an Erlang and makes it available somewhere through the iderlup install <id> <repo>, install a pre-compiled Erlang fromerlup default <id>, as iserlup delete <id>, as iserlup show, rename oferlup list
And you think we should rename switch to use?
rustup only has one command to switch around between toolchains, i think default, switch or use are all fine names, i just think it should be a single one
@lrascao hm? But you need a command that can set the global Erlang to use and one to set the Erlang to use for the cwd.
Maybe i'm missing something then, i've never had a need for that. If i had i'd probably look for some other tool that switches Erlangs on the cwd kinda like direnv does.
If you used direnv but didn't have this feature to set it per cwd then it would be still global. So you'd change to a directory in one terminal and now even in any other terminal you have the Erlang used is changed.
We could just copy rustup's commands for this: https://doc.rust-lang.org/nightly/edition-guide/rust-2018/rustup-for-managing-rust-versions.html#managing-versions
They use default like erlup does but instead of switch <vsn> it has override set <vsn> to do the same thing (per-directory version to use).
nah, if it's just naming then this way is fine
Can also configure overrides the way they do. Right now it creates a file in the cwd, ./erlup.config. rustup adds the override to the global config, like:
[overrides]
"/home/tristan/Devel/erlup" = "nightly-x86_64-unknown-linux-gnu"
But you can also manually create the file rust-toolchain in the cwd so you can check it in.
I think I like that better than always creating the file in the cwd. But getting off topic at this point :), I can make issues for that stuff.
The nice thing I see now about using override instead of switch is the other commands that it has:
SUBCOMMANDS:
list List directory toolchain overrides
set Set the override toolchain for a directory
unset Remove the override toolchain for a directory
So maybe override is a better name than switch.
And yea, show instead of list sounds good.