Taking Inno Un/Installer seriously

[rapus95]

Installer

Now, that the installer was replaced we might finally add some options to the gui (will make the NEWS.md more satisfying 😁)
Ideally I'd envision an installer with the following options:

Path to install: <path>

[ ] Update PATH to point to the new version (replace previous references)*
    [ ] Uninstall those previous versions from disk

* This will allow Julia to be run by typing "julia" into the command prompt or
execute window (Win+R) without any further setup.

---

The first checkbox would search for paths which point to a Julia bin directory (& contain "julia" in their path string, to prevent unexpected side effects) and replace them with the path to the new /bin.

I'd consider checking that box by default if a previous Julia already is on the PATH.
That way, installing the new version feels more like an upgrade path rather than leaving the system cluttered with outdated versions. (Or manually needing to uninstall an old version where I sometimes expect to accidentally remove shared data)

---

The second checkbox would call the uninstaller in all directories which were found in the previous step. Here it's rather controversy which option to take by default.

---

This would fit nicely into the less system oriented workflow of Windows users like me 😄 (=point-and-click-adventure-like installer)

As I've no clue how Inno setup works, the following might help:
https://stackoverflow.com/questions/3304463/how-do-i-modify-the-path-environment-variable-when-running-an-inno-setup-install
https://stackoverflow.com/questions/2000296/inno-setup-how-to-automatically-uninstall-previous-installed-version

Uninstaller

The uninstaller on the other hand should provide some checkbox for "delete global configuration" which would also delete the .julia directory.
Might be marked with some warning to only check if no further usage is wanted.

The uninstaller currently states "Do you want to remove Julia-#### entirely?" which leaves me in a state to fear accidentally removing the global state. If it was a checkbox that'd be clear.
Also, optimally people won't need what .julia does/is for. (Well, once manual cleanup to fix bugs isn't needed anymore 😛)
And thus we should cover that cleanup in some way aswell.

[KristofferC]

It would be good to separate the concrete change

First I want to note that the default directory changed compared to the previous version (Julia 1.3).

into its own issue and then the more speculative can be kept here.

[musm]

All of those should be doable and improve the experience.
But I do feel like the path update suggestions might be too cute. I think chocolatey kinda already solves that problem with upgrades and so forth, but I haven't tested it recently with Julia.

Personally I just rename to julia install to install it to a folder names Julia-1.x and haveJulia-1.x/bin added to path (actually I just have a julia calling function in my powershell profile).

[rapus95]

Well, in the other issue you said the default path changed to have everything in the same place. Here you say you manually change the path to always install to the same directory. That way you have the upgrade experience without changing PATH env.

So it seems like providing an upgrade path sounds like a good idea. Now, that all Julia versions will by default install into the same directory it might be a viable solution to link to a script in Programs/Julia/ which in fact selects the highest available version to be run (wherever that was installed to). That script could be updated by the installer if the corresponding checkboxes are enabled. If checked, that script should be added to path aswell IMO.

[rapus95]

Maybe that could even go into 1.4 as its not a language feature. That way we would only change the installer experience once and make it a lot better in a single step.

[KristofferC]

1.4 is in bugfix mode, something like this would not be backported.

[rapus95]

Oh, I thought it's rather a part of the script for building the Julia installer than actual part of the language and its repository. Thus I thought installer-packings would somehow exist independent of the actual language.

[StefanKarpinski]

Anything that needs to be tested and made sure to be functioning correctly is included. If we let people keep making functional changes to things then we would never get releases out.

[rapus95]

To precise what I meant: I didn't expect the installer configuration be part of the feature freeze/language spec. And for the gui case especially not part of the API. Thus I expected more freedom in how to pack the installers. But then I may ask, will these changes need a new patch release or a new minor release?

[StefanKarpinski]

Does the installer configuration need to be tested and made sure to be functioning for a release? Yes. Therefore it is included in the feature freeze. There's a little more leeway, but not much. I wouldn't worry about which release these get included in, just focus on the way it should work, get it working on master and then we can sort out the release. At the moment, 1.5 is open.

[musm]

Well, in the other issue you said the default path changed to have everything in the same place. Here you say you manually change the path to always install to the same directory. That way you have the upgrade experience without changing PATH env.

So it seems like providing an upgrade path sounds like a good idea. Now, that all Julia versions will by default install into the same directory it might be a viable solution to link to a script in Programs/Julia/ which in fact selects the highest available version to be run (wherever that was installed to). That script could be updated by the installer if the corresponding checkboxes are enabled. If checked, that script should be added to path aswell IMO.

Yes, but I have my own custom setup because I want things organized in a special way, since I have multiple version of julia installed for various development reasons.

I am a bit hesitant to get too fancy with the installer/uninstaller. I'll try to take a look how to improve things at some point. We might have to backtrack on some things like changing to install folder back to just Julia instead of Julia/Julia-1.x.

[musm]

@rapus95 In #36518 I implemented the option to Add Julia to Path.

[GunnarFarneback]

I'd be delighted if the installer also had an option to configure the package server address, i.e. setting the environment variable JULIA_PKG_SERVER to a user provided address. Then I wouldn't have to guide my Windows-using colleagues about setting environment variables manually at all. :-)

[musm]

How would the UI for that look like? I would imagine we need to be careful so to not confuse people that don't need to set this

[musm]

In terms of the "auto-update" installer.

What I have figured out is the following.

1. Implement: Add to path functionality, with automatic removal from path upon uninstallation.
2. Auto-update: Checks if Julia is already is installed, offers user to uninstall previous version (which will remove julia from path, if already added), then installs the new version updating the path if selected.

For the auto-update, here's the UI for the whole upgrade process:

[GunnarFarneback]

How would the UI for that look like? I would imagine we need to be careful so to not confuse people that don't need to set this

Three options.

• Use default package server. (Leaves JULIA_PKG_SERVER unset.)
• Disable package server. (Sets JULIA_PKG_SERVER to "")
• Use custom package server, with a text edit field. (Sets JULIA_PKG_SERVER to the entered text.)

Probably needs some text about the first option being good if you don't know what the alternatives mean. Possibly the second option could be skipped since it can be accomplished with an empty string in the last option.

[KristofferC]

I don't think the installer needs a way to set a package server. The vast vast majority will want to use the default one.

[Roger-luo]

I think most people in mainland China will need this feature (let the installer set a package server which is not the default one), tho @staticfloat just finished a few local public servers and might get pkg.julialang.org/pkg.juliacn.com to redirect to them. But I think it'd be great to let the user decide which to use with a UI since this is at least a friendlier way than changing environment variables. I found people had trouble changing the server address with environment variables, especially on windows.

[KristofferC]

In that case a dropdown list would make sense to me.

[GunnarFarneback]

I think you underestimate the potential of running in-house package servers and the value of minimizing the friction of installing Julia in such places.

But actually, what I suspect I really want is a package that lets you build your own installer with the right choices pre-configured.

[StefanKarpinski]

The Chinese pkg servers should be automatically redirected to from the default pkg.julialang.org and should not need to be selected by the user manually. It would be fine to have a simpler mechanism for selecting a different package server, but it should not be necessary for anyone using public pkg servers.

[BioTurboNick]

Just dropping in to say that an option to launch the uninstaller for a previous version would be a nice way to keep extra versions from accumulating if you don't need them. Just realized I had ~10 different copies sticking around.

[mgkuhn]

@BioTurboNick You merely have to specify an existing installation directory on the command line with /DIR=..., and Inno will replace the previous installation with the new one there.

I install Julia on Windows with something like

julia-win64.exe /VERYSILENT /DIR="C:\Program Files\Julia"

and it overwrites the previous installation there.

@GunnarFarneback If you want to make it easy for your colleagues to install Julia in some customized what, e.g. involving changes to their environment variables, just place the call to the installer with /VERYSILENT into a PowerShell script, from where you can also very easily make any changes to related environment variables, as needed. Windows comes already with at least one a Turing-complete scripting language, hence there is no need to reimplement such functionality in each installer.

P.S.: I actually update Julia on Windows remotely via SSH, and there you need the /VERYSILENT option because OpenSSH sshd runs as a service and thus can't run any programs that try to access the desktop GUI. If you want your setup to be reproducible, avoid any GUI steps in setting it up.

Inno Setup help for command-line parameters: https://jrsoftware.org/ishelp/index.php?topic=setupcmdline