Incorporate an add to PATH option in Windows Inno Setup installer

[musm]

This adds an unchecked by default option to add the Julia bin directory to path on Windows for the installer.

The code handles adding the bin to path and also automatically removes the path upon uninstallation.

Part of: #34495

[vtjnash]

I'm inclined to think it should be unchecked by default, to reduce the risk of breaking other software that uses Julia internally, but happy to hear what other languages do (looks like python is non-default, while nodejs is probably default checked):

[musm]

Rust adds to path a whole bunch of .exe files by default, same with vs code.

I'm inclined to leave it selected by default, because beginners often struggle with 'adding to path'. I'm also happy to hear others on this.

[musm]

If there aren't any objections can I merge this?

[rapus95]

One remaining question for me, what will it do if Julia already is on the path?
if that currently can't be handled in a meaningful way, what about the idea in #34495 (comment)
in combination with #34552 (comment)
Especially the latter comment seems to be fallen by the wayside.

[musm]

That's a separate issue, I'd like to tackle in a different PR. This PR only adds it to the end of the path list, and the corresponding uninstaller will remove it from path list.

For the "update" strategy. Right now the simplest method that I got to work, is for the installer to check if Julia is already installed and if it is, the installer will then ask you if you want to remove the previous version. Removing the previous version will then remove it from the path and then the new installation will add the new version to path.

[musm]

I posted a comment regarding that in #34495 (comment)

[musm]

I just read over #34552 (comment)

It's an interesting proposal.

Can you explain in more detail how the exported_binaries directory would work? Like, is the idea to create symlinks from the julia bin directory to the ~/.julia/exported_binares folder?

How about adding a new directory to the ~/.julia path, something like "exported_binaries" which will hold references(or executable scripts) to all binaries that should be accessible via the path. That'd have 3 advantages:

[rapus95]

Can you explain in more detail how the exported_binaries directory would work? Like, is the idea to create symlinks from the julia bin directory to the ~/.julia/exported_binares folder?

The idea was that the "exported_binaries" directory will contain all files that shall be in the reach of the path variables. So right now, there probably will only be a script which leads to the right executable. So right now the idea might sound weird and unnecessary. The idea is that it'll establish a place where we/the Julia compiler later can put the "exported as binary" programs to once binary export lands.

EDIT: I had some quick thoughts about it again and we could drop the "binaries" component in the name. Then we could plausibly use that directory as output for some "runnable scripts" package which accepts a julia script and a name to create a batch file in that directory which executes the provided script.
E.g. I have some script doStuff() in file "ABC.jl" and want that to be callable via doit on the commandline. Then I call a package Scripter.jl which creates a doit.bat which contains julia -e "doStuff()" path\to\ABC.jl. But where should that go to?
Now, if we called it something like exported_programs then that directory in .julia would be the perfect place for such a .bat endpoint and that directory will only introduce a single line to the path list but still can hoard/hold all my QoL scripts written in Julia.
Once we have the capability to actually compile full scripts into binary .exe executables that directory will already be the established central place and could even be augmented with stuff like automatic binary upgrading on code changes.

In summary I guess the language has a lot of potential to scale into such a central established script/program place.

To come back to this post's topic, the "julia" command could be the very first citizen of that new directory. That Script will just redirect the call to an actual Julia executable. Ofc, highly customizable, as we all like it. In that far future with Julia-compiled programs, running something via Julia and running something made by julia would become indistinguishable. Since both will have entry points in that directory.

[musm]

Unchecked by default now.

Is that text at the bottom helpful? I kinda want to remove it.

[rapus95]

I kinda like it but it only holds information for those people who also know what the path is anyway. So I'd rather replace it with a suggestion for those who don't know what it means

[musm]

Doesn't that explain it well enough? What to do you think it should say, without being too lengthy. Looking at other languages e.g. Python, GIT they do a much worse or no description at all.

[rapus95]

I mean that I'm actually very sure that there are a lot of people who don't even know what the command prompt is. But those who do don't need an explanation.

[musm]

? Maybe replace command prompt with terminal

[rapus95]

I have a salty moment right now which makes me think whether "if you don't know if you need it, ask the person who asked you to install it" would have an appropriate amount of humour 😇😂

[musm]

True best to remove It. Merging this PR after updating it with an unchecked default.

[rapus95]

I think this option's only use would be for people who write julia code for other people since it helps setting up script based automation. that brings me to another idea which is entirely independent of this issue:
How about adding some function to System which adds the own executable to the systems path. That would have 3 advantages.

1. we can leverage julia for it (including checking for its existence or replacing/updating old links)
2. you don't need to decide before the actual installation and it also automatically leads to a function to remove it at any time.
3. it's easy to explain to someone who doesn't know coding (just run the program and type somecommand())

[musm]

@rapus95 please look at #36672 it will be the future installer and basically with juliaup all the issues you have are fixed.

Right now this is an incremental improvement and it can help as a stop-gap solution for newbs who don't want to go through the hassle of adding to PATH and just listen to the instructor that tells them to select this option and get going.

[rapus95]

for newbs who don't want to go through the hassle of adding to PATH and just listen to the instructor that tells them to select this option and get going.

Erm now I'm confused, thinking
found out I confused myself 😂😂 somehow I thought you'd remove the path option when we were talking about removing the tooltip since anything beyond "ask your instructor" probably wouldn't help anyway... Sry for always coming up with new ideas which almost run contrary to the existing concept 😅🙈

[musm]

No problem! Your input is appreciated

[davidanthoff]

Should this really have been merged before #36588 is done? This now adds a lot of DLLs onto the PATH, pretty much everything that is shipped with Julia, which I thought was always considered not a good idea?

I had always assumed that if something gets added to the PATH, it should be a folder that contains only a julia.exe or julia.cmd or something like that.

I should say that I'm not super clear how important that policy actually is, but it was for a long time here and I'm just surprised that it was given up without some discussion of what has changed?

[musm]

The "ADD to Path" option is unchecked by default.

[musm]

Should this really have been merged before #36588 is done? This now adds a lot of DLLs onto the PATH, pretty much everything that is shipped with Julia, which I thought was always considered not a good idea?

I'm not sure why that should change whether this should get merged before or after. The option is by default unchecked. This is still early in 1.6, so after staticfloat's PR the situation will be improved w.r.t to the dlls getting added to path (granted I personally haven't had this issue, but understand it's possible). If the path that we need to add to PATH does indeed need to change, it will be trivial for me to update the location that get's added to Path. So no I don't find it an issue when this got merged.

[rapus95]

Tbh I always just put julia/bin to PATH w/o caring about the other files... Now I at least can make that happen w/o having to manually change the environment variables. Whether that's a good idea IMO is out of scope of the capability to do it. So in my opinion that's just a feature for convenience which makes it independent from the other issue.