Add juliaup-init installer for Windows, Linux and OSX

[heetbeet]

Related to #84

[heetbeet]

I have written the installation script as a polyglot in order for the same script to run on sh as well as Windows Cmd+Powershell. I have done some extra work on the installation side to integrate with the environment, that should eventually move to juliaup self install:

• On Windows we prompt the user if they want to add to PATH and then automatically do it for them.
• On Windows we copy julialauncher.exe as julia.exe in order to overcome the frustrating lack of symlink privilges
• On *nix we symlink julialauncher as julia right next to it
• On *nix we guide the user into adding juliaup & julia to their path, eg.

To add juliaup to PATH, run:
    sudo ln "/home/simon/.juliaup/bin/juliaup" /usr/local/bin/juliaup -s
    sudo ln "/home/simon/.juliaup/bin/julialauncher" /usr/local/bin/julia -s 

#104

[PhilipVinc]

I tested the script on Mac.
It runs fine, however the message add julep to PATH should be changed from sudo ln .... -s to sudo ln -s ... because I believe ln in macOS is not fully compliant...

➜  ml-intro sudo ln "/home/simon/.juliaup/bin/juliaup" /usr/local/bin/juliaup -s
Password:
ln: -s: No such file or directory

[c42f]

It looks like this could be useful, and I think it makes a lot of sense just to copy rustup's implementation. Could use a link to their source repo I guess.

The polyglot script is very entertaining but from a practical standpoint it seems more complicated than useful. Can you explain why it's better than just having two separate scripts?

[c42f]

I don't think we should recommend linking things in $HOME to things in /usr/local.

• /usr/local is a system-wide install location
• $HOME is specific for your user

If there's any other users on the system this won't work well for them as all the files will reside in your specific $HOME directory with your permissions.

---

A better alternative is to recommend the use of the $HOME/.local/bin directory which is part of the XDG standard:

User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.

Perhaps juliaup itself could be installed into $HOME/.local/bin/juliaup and we could skip the symlinks completely? If that's not possible, we can symlink it in there.

See also https://unix.stackexchange.com/questions/316765/which-distributions-have-home-local-bin-in-path

[heetbeet]

Good point, it's messy symlinking user-level things to system-wide directories. Will think a bit about this... It might be worth asking the user if the path should be appended in ~/.bashrc like conda and rust does is. I have a strange feeling about installing it flat into $HOME/.local/bin/, since I want to be able to delete the whole directory (such as ~/.juliaup/bin) and not have side effects.

[c42f]

So... this way of combining sh and cmd and powershell within one script is clever and entertaining. IIUC

• In sh mode, this first part is treated as a heredoc and skipped.
• As a cmd script, the part above is a cmd bootstrapper to run powershell with the content of the file
• As a powershell script, the whole first part is skipped and the script starts at line ~750

It's pretty amazing that can be made to work, but practically it also seems unnecessary and complicated!

Wouldn't it be cleaner just to have one script file for windows (cmd+powershell) and another for unix? I guess I just don't see the advantage in combining them. This would also reduce divergence with the original unix script at https://github.com/rust-lang/rustup/blob/master/rustup-init.sh

[heetbeet]

Will split to julia-init.sh and julia-init.cmd

[c42f]

Was this script also derived from somewhere else, or is it completely new?

I'm no powershell user, but rustup had interesting commentary on their equivalent thing in rust-lang/rustup#1878, though it seems that was never merged.

[heetbeet]

I wrote the script from scratch, I didn't know that there were a rustup .ps1 in the making, will have to go and see if that is a better approach.

[heetbeet]

I see they are building a cross-platform Powershell solution with quite a discussion on using Powershell idiomatic arguments. The purpose of my Powershell implementation is to get something working on the Windows side and to mimic the .sh script as close as possible. So I think I'll keep it as a .cmd file, to distingue it from a cross-platform Powershell solution, and also that is can run under stringent Windows security settings (e.g. running powershell scripts directly is disabled by default on Windows).

[PhilipVinc]

did this PR stall? I think it would be great to have it... I can contribute some work if needed

[davidanthoff]

Sorry that I sat on this so long, too many other things going on! BUT, this is fantastic!

I reviewed the Windows version pretty carefully, and one problem there is that the binaries we compile right now require a MSVC runtime that I think we can not rely on being present. When we deploy via the Store, this is not a problem because we declare that we need those and then the Store installs it for us, but we won't have that for this version. One option (I think) is to compile another version of juliaup that uses the MINGW stack and use that here, I think one can either statically link the runtime in there or it would presumably use the same (outdated) VC runtime that ships by default with Windows. Or something like that...

Another thing we should do is copy the install script as part of the release GitHub workflow somewhere, and then reference that location to users, i.e. not have them use the version on master here.

How about this: why don't we merge this as is for now, but remove the mention in the README? I think we should really only start to advertise this once we also have the self-update mechanism in place. But if we just merge this for now without mentioning it in the docs, then devs can try it more easily and we can improve with incremental PRs.

@heetbeet if that sounds OK to you, do you just want to remove the README edits, and then I'll merge?

[heetbeet]

Thanks for the merge, sorry this was on my todo list, but it ultimately fell off while trying to finish my academics before the end of the calendar year