A graphical Julia installer for Windows

General Usage
21

My 2 cents;

  1. Why not help improve the existing gui installer?
  2. Why not make a gui installer and driver for juliaup?

idk how hard #1 would be but #2 sounds much simpler to accomplish and frankly, more helpful, than writing something completely from scratch.

it sounds a bit like you are interested in creating a prepackaged coding environment. why stop at offering to insta an editor? offer some nice packages like dataframes and http, precompiled during the installer, and send them happy on their way. like eg winpython. I don’t think ive seen it for julia but im sure some people would appreciate it.

As for officiality of the installer, every single open source language that i know of, that has been established for a while, has multiple different installers catering to different needs. this is not matlab and not mathematica. as others mentioned, even the official ones were once unofficial.

make it good and it will be adopted. or help make existing ones better.

PS

Personally, i would find the offer to install vscode highly distasteful in the official installer. i can choose my IDE myself, don’t patronize me - thank you. if it was an unofficial bundle, sure i might even use it in certain cases.

3 Likes
22

Ahhhh, interesting. I didn’t realize that there was an alternative MSIX/MSI installer for juliaup since they aren’t mentioned on the JuliaLang “Install” or “Download” pages. I’ll definitely give those a try when I get a chance.

1 Like
23

Because I was told here in different threads that it is not recommended to use it (too buggy or whatever, I don’t know). I don’t know why it is not maintained and I can’t find its code on Github.

Because juliaup is a complete program. So it would be to write a UI for that program. That is a completely different task than just to setup a graphical installer for Julia. When I write “installer”, I mean just the one-time called UI program that unpacks file of a software, set registry entries etc.

As you wrote by yourself, the goal is to offer a complete setup. That means you can uncheck the option to get vscode. My idea is just to offer an IDE because as newbie you must have something you can start with. vscode has an officially supported Julia plugin.

24

If one wants a one-click installer of both vscode and Julia, there is
PetrKryslUCSD/VSCode_Julia_portable: Portable Julia running in VSCode
@uwestoehr Perhaps you could slap a GUI installer on top of that?

2 Likes
25

But that’s exactly my point. Julia is not just a “learning language”, although it certainly is great for learning as well. I wouldn’t want to uncheck or even be offered to install any additional software when installing a new language/compiler.

It’s quite rare, actually, for FOSS languages to offer to install an IDE as well, and even rarer to offer one that is not specifically tailored to the language and moreover has strong corporate ties like VScode, in the official installer. Can you name 2 other languages that do this?

And if you do offer an IDE, why vscode? I want Emacs, personally. Here you are confirming that you want to make a “starter kit” sort of offering, which is great but shouldn’t be official by any means. And could actually be useful in its own right.

I just spent a couple of minutes on the julia GH repo to find this: julia/contrib/windows at master ¡ JuliaLang/julia ¡ GitHub
Is this not it?

Looks like this code indeed hasn’t been touched in a while - your opportunity for quick gains. Make a PR :slight_smile:

It is not recommended because there is a better method (for most cases), which is juliaup! I used the installer in the past and it worked fine. Perhaps address the bugs you encountered yourself? that would be helpful.

Maybe a rewrite from scratch would be easier? idk. Just don’t push other software into it, please if you ever want it to become “official”. it will be a huge nuisance and dilute the julia brand imho. and be harder to maintain.

PS
Most modern languages - esp ones that interpret/compile code at runtime and/or are under heavy development - have version managers. This includes node, ruby, python, go and rust, some of the most popular languages for new projects. python on windows, as installed from the MS store, comes with a version manager. And is installed to user dirs, not into program files.

26

Yes, we should add a mention of that on the page.

2 Likes
27

I suddenly felt the need to latch onto this metaphor. Sorry about that.

I would say the boat isn’t steered by those shouting from the shore, but by those who got aboard and started rowing.

Unlike with an actual boat, though, people rowing in different directions simultaneously can work just fine.

Personally, I’m a passenger, and I’m greatly enjoying the ride, but I also don’t expect to be able to set the course.

Anyone can do almost exactly what they want, but not necessarily decide what others should do. You decide by rowing, and the harder you row, the more you decide.

16 Likes
28

The point is that I prefer to discuss things BEFORE I act. I have no spare time to lose. Creating an installer cost me some time and then a steering committee denies it and I wasted my time.

1 Like
29

First now I realize that this thread was already marked as solved 15 days ago. But why was this done? I don’t understand who makes the decisions and here I can also not see what the decision is. Was it decided not to have a graphical installer and who decided this in what basis?

30

The topic’s creator and some regular users would have the ability to mark a solution, but forum participants conventionally leave it up to the topic’s creator. I assume someone misclicked, but they’re not listed so we can’t verify what happened. I unmarked it for you as I wasn’t sure if you could unmark that yourself, but you could try if it comes up again. If you don’t eventually mark it, it’s more likely participation just peters out, there’s plenty of unresolved topics here.

1 Like
32

Thanks.

It was not clear to me that everybody can just mark a topic a resolved. I did not create this thread but it was kindly created by a moderator as a spin-off from another discussion. Therefore I thought only moderators can close/resolve the thread.

33

OK, what about this: unless there is no objection the next days, I will create an installer as proposal and put it on GitHub.
Then there can be a further discussion about the features it should have.

3 Likes
34

The post that was marked as the solution said something along the lines of “Don’t we already have a graphical installer for Windows? If it’s buggy or inadequate, the best thing to do is probably contribute to its maintenance.” A regular on this forum probably considered that an adequate response to this discussion topic and therefore marked it as a solution to the thread. That’s just a forum moderating decision and has no bearing on future Julia development. This forum doesn’t make those decisions.

35

Only users with sufficiently high trust level can select solutions for topics they didn’t start themselves. On this forum, I think the required level is “Regular”. You earn trust by being a regular reader and contributor, as detailed here: Understanding Discourse Trust Levels. But the point stands that this is a power granted to many regular users, not just moderators.

36

Still worth emphasizing that this isn’t common practice. I’ve never had any of my topics resolved by another person, even when an obvious answer is there. I was always afforded the choice to let the discussion continue a bit longer before I marked it.

37

For inspiration, here’s how it looked when juliaup was announced to the wider dev community: Juliaup version manager · Issue #36672 · JuliaLang/julia · GitHub. Summary of the timeline:

  • 2020 July: New Windows MSIX installer with version multiplexing capabilities announced to the julia dev community in a github issue. Usable prototype available for download.
  • 2021 May: Installer signed and uploaded to the Windows store, unlisted
  • 2021 July: Installer made public in the Windows store
  • 2021 August: Installer rewritten in Rust and made cross-platform (Windows, Mac, Linux)
  • 2022 March: “I think we may be ready to start advertising it on the downloads page and such”, github issue closed
11 Likes
38

I, for one, hope that juliaup does NOT become the default or only way to install Julia–as some are already promoting–until juliaup is easier to install, vastly simpler and more lightweight and better suited to people who are not developing Julia itself or significant Julia packages (a hugely important constituency to be sure!).

It leads to cached installations of multiple version; some difficulty with paths; and doesn’t solve the “how to get compatible packages” after an upgrade of the tenths digit of the version number.

If this is a goal, I’d recommend splitting juliaup installable into 2: one for maintainers/developers and one for us simpleton users. Of course, most of the code would be identical–the simpleton build just does less and suppresses various options. The same once could have been said for Pkg, but that’s very well-solved (has been for a while) by the great Pkg REPL.

The “out of box” experience is a really big deal. My foray into juliaup didn’t feel as nice as dmg installer on Mac and the Windows store for Windows. And, yes, I have successful, nearly equivalent installs on both a Mac and a Windows machine. And having tried juliaup twice, I saw no benefit for my uses.

2 Likes
39

I cannot understand that. I find juliaup great. At least every year there is a new Julia version. Even more often there is a new minor version.

Juliaup makes it trivial to upgrade to a newly released version. And to downgrade when it is not good enough yet for your tasks. I think that is important even for beginners. Perhaps not in the first month, but at least after a year you are happy if you can easily run your old projects with an older Julia version and your new Julia projects with a newer Julia version.

And to get compatible Julia packages, you need to learn how to use Julia projects. See for example: Working with Julia projects | Julia programming notes

And if you switch Julia versions often, you also need version specific manifest files, like Manifest-v1.11.toml and Manifest-v1.10.toml. This is not yet explained in this blog post.

9 Likes
40

This is supposed to be a feature. Different projects may require different julia versions due to the compatibility restrictions of the packages they depend on. Casual users are not exempt from this. That said, I understand that it can seem daunting to have to stay on top of which versions are installed and which one to use for each project. If/when Launch the manifest-specified Julia version v3 by davidanthoff · Pull Request #1095 · JuliaLang/juliaup · GitHub or something similar is merged, you won’t have to think about this anymore. I think that would be a big quality of life upgrade.

I don’t think there are any path problems if you use VSCode or a terminal-centric workflow where you first open a terminal with a shell and then launch Julia from the shell? But I suppose if you want to launch Julia like an app, directly from Spotlight/Start Menu, or want to be able to run scripts by double-clicking/right-clicking in a file browser instead of running julia script.jl in a shell, a juliaup installation may not set up everything you need. On macOS, I guess juliaup could provide an option to download and install the dmg image instead of the plain executable, similar to brew install --cask.

The most user-friendly design would perhaps be if the Julia VSCode extension could transparently manage Julia installations (using juliaup under the hood). That way, casual users could have a matlab-like experience where there’s no discernible separation between the graphical app where you edit and run files and execute commands on a prompt, and the actual executable compiling and running your code. Just install VSCode (an easy and familiar process), open it, and install the Julia extension (a quick search and a single click).

In general, this would have to be Pkg.jl, not juliaup, as juliaup cannot know about all the project environments that may exist in your file system and, for each of them, whether you want to migrate to the new Julia version. However, it would definitely be nice if it helped you migrate your default environment to the new Julia version (basically just copying over the Project.toml and running julia -e "using Pkg; Pkg.instantiate()"). And once again, the VSCode extension could presumably help out with managing/upgrading other environments.

4 Likes
41

Suffice it to say, we disagree. And we are doing it politely.

Installing from a binary download is easy also. Installing with Juliaup is also easy.

For people developing packages or experimenting with bleeding edge packages–both reasonable things to do–changing your Julia version may make sense.

I have a simplifying philosophy though. I always use the latest released Julia version if it seems solid. They’ve all been very solid ever since around 0.9. I use the latest versions of packages. I’ve only experienced Julia version specific problems with a package once. I tend to use pretty popular and mature packages. That might not always be the case, but it seems a frustrating path to always be chasing down package v. Julia compatibility issues. Better to wait until a package developer has sorted things.

I try to write my own code so that it is not dependent on any particular version. I try not to use new features the first time they are available, but do after a revision or two (tenths digit of version number). My code won’t be released as packages for others so I am not expecting others to adopt my philosophy.

This makes my life with Julia very simple and productive. Again, we can disagree. You gave solid reasons for your preference. Perhaps my reasons for my preference don’t seem so solid to you, but they are to me.

Julia is incredibly versatile and I am always pleasantly surprised when someone brilliant has thought of a need I didn’t realize I had and there it is–already satisfied. There are lots of very advanced tools and packages in Julia that serve people well and allow more future innovation. It’s always worth remembering that the out of box experience for noobs also matters. We should remember that we were all noobs once; I probably still am. It seems possible to “keep it simple” and enable remarkable versatility. It has been so far and let’s hope it can stay that way.

2 Likes