Juliaup: a modest suggestion

Internals & Design
1

I might suggest that juliaup not be the recommended way to install julia and manage julia installations.

Before the cognoscenti jump on me, let me explain why and, then, propose a compromise position, if indeed any easy compromise that is really a “best of both worlds” position.

juliaup primarily meets the scenario of “multiplexing” julia, which is to provide an easy way to have multiple versions of julia installed; to easily switch from using one version to another and to remove versions that are no longer needed.

It may be my extreme misunderstanding but this scenario is mostly (but, not exclusively) a benefit to the brilliant original developers and other equally generous and capable current maintainers of Julia. Similarly, this scenario is crucial for maintainers of broadly used (or any) packages that reasonably target more than one recent release of Julia. juliaup dramatically simplifies this important work.

At the same time, this scenario is of less (not no) benefit for ordinary “users” of Julia: subject matter experts focusing on simple .jl files to do their work or packages that serve the function of being “applications,” as defined in the Pkg documentation. Note: I use subject matter experts here casually, meaning anyone who wants to do their work in Julia, or learn Julia or simply experiment. It is not that such folk might not also see benefit in having concurrent access to multiple versions of Julia: only that this need is perhaps less urgent for them.

Of course, it is a choice of whether or not to use juliaup. So, there must be some reason to not recommend juliaup as the preferred installation of Julia:

  1. juliaup is arguably a more technical install the first time than Julia itself;
  2. It helps further adoption of Julia to have a default installation that is simple and native to each platform Julia runs on.
  3. Juliaup installations have a couple of difficulties. The only one I have encountered is setting up SublimeText with julia language server support. That is arguably (ok, a really good argument) the fault of those SublimeText package developers, but as truly awesome as the VS Code support for Julia is (my personal number 1 for lots of things!), I find some benefit in having a quicker, lighter editor. Others might like emacs (!!???!!!).
  4. The uninstall method recommend for juliaup effectively breaks the completed installation because all paths to running julia lead through juliaup. Now, in 3 minutes I easily moved julia; fixed the path setting in .zhrc by moving the complete julia installation out of juliaup; commented out the juliaup portion of .zhrc (until I could verify that my changes all worked); created a symlink to the julia binary in /usr/local/bin, and manually edited the json of one jupyter kernel. oooh, sort of a longish list. But, easy enough once one realizes it is just a matter of moving a directory and finding every path set to it. Still, not something everyone could (or more likely, wants) to do. What was important here was preserving my current nicely working Julia installation and saving the work of a full install (easy enough without juliaup) and more importantly the package management (a scenario juliaup does NOT enable–which is arguably a benefit for more of Julia’s users).
  5. We should want to encourage Julia maintainers to provide platform specific, very simple installations that are easy and reliable and not fall back on juliaup for all users, which might encourage new trials and future adoption of Julia.

The net is to suggest no longer recommending juliaup as the preferred installation. The compromise, and an easy one I think regardless of one’s preference, is to suggest either the platform specific installation or juliaup with a brief explanation of the benefits and slight disadvantages of each:

  • platform specific: path setting consistent with most other command line tools on said platform and a simpler 1st time installation. Disadvantage: can’t readily switch between multiple versions, if installed. [Note that Julia already cleanly allowed multiple concurrent versions to be installed, but users would need to be clear about how to identify appropriate versions and manage paths.]. The difficulty of multiple concurrent versions regardless of the method chosen is installing and managing packages for each version (though installation is required, using environments properly simplifies this considerably–but might be a more advanced thing for those just starting with Julia). Better support for non-Julia tools (jupyter, Sublimetext being the only ones I have direct experience with).
  • juliaup: a one time install that is a little more technical and then absolute ease to install and be able to quickly enable/disable specific versions, with emphasis on working with packages (especially as a developer/maintainer) across versions. Acknowledging switching back from juliaup (currently) requires reinstallation of everything Julia.

So, it really is a best of both worlds. My only point is that there are two worlds and noobs, while not garnering a lot of respect, occupy an important world. We–or at least “I”–started as noobs and some of us struggle to climb up above noob-hood.

Sorry, this is so long: I anticipated many objections and wanted to pre-respond if I could. There are certainly things I don’t understand. There is also the potential for juliaup to evolve and be preferred in both worlds. Thanks for considering this position.

8 Likes
2

I actually find juliaup really easy to install, and it doesn’t only allow multiple versions of julia (something end-users don’t really need) but it also tells you when a new version is ready to install, allowing you to keep having a supported release, and it also allow for very easy upgrades of julia. I’m actually really happy about juliaup

26 Likes
3

Agreed. The biggest reason-d’etre/advantage of juliaup for me is the (mostly) automatic upgrades. As a long-time package developer, I occasionally need to switch versions, and for that it is indeed convenient, but the main reason I use juliaup is to get minor/patch releases in a timely way without having to watch so much for myself when they’re available.

19 Likes
4

Well, I think most users of Julia will develop a project at one point in time using Julia version X, and the next year they might develop a new project using version Y of Julia, and using a new Julia version might break their old project from last year.

I know, new Julia version should NOT break old code, but my experience is that they often do, perhaps because I (or some packages I use) use Julia internals.

I don’t know for how many years you are using Julia, but after one or two years you will start to rely on juliaup because it makes it so easy to use old Julia versions for old projects and new versions for new projects. And I can just delete my .julia folder and launch Julia again, and it gets re-installed automatically… That is like magic. Again, it should not be needed, but if compiled packages are corrupt it sometimes is needed.

7 Likes
5

That’s not my impression. juliaup is really very easy to install, and it installs and manages Julia in a very easy going way.

Well yes, but that’s precisely what juliaup does !

I always install Julia with juliaup, and I never had any issues, with sublime text or with vs code.

Not sure what’s the problem here. You’re saying you’d prefer to have the Julia binary at /usr/local/bin? I have to say that I strongly prefer it living in ~/.julia, which I think by now is the standard location. For one, this is helpful for cases where you install in a system where you don’t have sudo access.

Yes, again, that’s precisely what juliaup is doing.

7 Likes
6

I found updating Julia to be a chore until I started using juliaup, that’s the main attraction for me. Juliaup is such a great simplification, I find it a bit difficult to understand what could be simpler, except if it had a gui on top, perhaps.

8 Likes
7

As I referred before what I dislike with juliaup is that, on Windows, it installs Julia under a hidden directory. Over time I wonder how many users accumulate previous Julia versions (~1 GB each) without even knowing that (unless they know how to make the hidden dir visible).

As for using multiple Julia versions for development, setting the Windows console to use any of the installed versions (without having to change anything on the system) is trivial.

image
image2468×679 43.3 KB

2 Likes
8

I’m not sure about that, doesn’t juliaup update release remove the previous one? When I upgraded from 1.11.4 to 1.11.5 I don’t remember having deleted the 1.11.4. Few days ago I upgrade 1.12.0-beta1 to 1.12.0-beta2 with juliaup update beta and the 1.12.0-beta1 has been automatically removed. At least in Linux it works like that.

9

I believe it does, but I was referring to 1.9, 1.10, 1.11, …

10

Unless you manually add them (and then you should be able also to use juliaup to list them and delete them), upgrading them removes the previous one as you can see from this older post Why does juliaup delete the old versions?

1 Like
11

Appreciate people’s kind replies and different perspectives. I’ve been using Julia for about 9 years. My philosophy on versions is to avoid doing things that are version specific until a feature has been in 2 or more tenths digit versions. And I tend to install the latest stable release that will receive longterm support and upgrade packages every couple of months or so.

In the early days, there was sometimes a wait for some packages to get necessary fixes but that is really a thing of the past now. The Julia release process is very disciplined. Package developers can see the latest commits and often have the opportunity to test and fix on alpha, beta and several release candidates.

Of all of the “new” languages, Julia is probably the highest quality, most professional, and best documented. So, I hope it came through that juliaup meets a real need, but not equally well for all users.

1 Like
12

The point is what most of the people uses-needs. If you prefer to use older releases it is your choice and it is fine, but most of the people, and also packages, often refer to the latest. I don’t know how it was 9 years ago, but today many packages are still being constantly developed, changed and fixed, it is hard for developers to keep stability across more versions and most of them suggest to use the latest release.

I’m not against your choices, but it is true that it is a small portion of the community, and probably leaders go in the direction most preferred by the community, which I think is the right thing to do

13

Binary lives in ~/.julia and not ~/.juliaup/… Only symlink in /usr/local/bin which is a very typical pattern. And I only did this to uninstall juliaup without using the juliaup uninstall, which would require reinstalling everything.

It’s really clear juliaup does a great job of managing multiple Julia installs and upgrading (though it doesn’t solve the re-installation of packages).

I only suggest the choice should be emphasized a bit more rather than so strongly proposing (not requiring–the docs clearly do not require juliaup) use of juliaup.

I think curl -fsSL https://install.julialang.org | sh -s -- <ARGS> is a bit of a technical thing though it’s a black-box copy and paste. Not everyone has homebrew installed. If juliap was the new .dmg installer on MacOS and setup for windows (and use OS package manager on Linux?) then it would be easier to install than it is today. It’s still a pretty complicated command line utility (because it does a lot!) but it could have very nice defaults (might already).

It seems it’s always hard to be the proponent of balance: simple is good and versatile/functional is good, but it’s not always easy to do both in one tool. I’ve used both. I wish there was a solution to migrating packages for new versions (I suppose I should write a trivial Julia script to do it with minor updates for some version to version transitions)–this would be of more help to me than multiplexing, but the multiplexing use case is super important for the advancement of the ecosystem–I get that.

I’ll rest on this. We have 2 ways and we can all prefer and choose either one.

15

You’re getting some pushback here, but keep in mind there is a self-selection here where the majority use Linux and are familiar with the command line. There is desire for a GUI installation wizard on Windows, perhaps something that encompasses what juliaup can do, just in a GUI. I know I do, even though juliaup works okay right now. The takeaway I had was, it’s not an unreasonable ask, but just a matter of someone putting in the work.

My only point is that there are two worlds and noobs, while not garnering a lot of respect, occupy an important world.

Fully agree.

4 Likes
16

I’m probably loosing what is the proposal. I’m fully favorable towards a gui installer (even though I’d prefer making Juliaup also installable with GUI, and not create a new one, also, isn’t Juliaup already with a gui on windows?). What I was saying is that I like Julia strongly recommending Juliaup. People who want a minimal installation can go without, people who want something more friendly can use Juliaup.

Comparing with python, the most similar thing to Juliaup that I know of is Anaconda, and before that I often found myself with old python, and the day I decided to update it I found all my codes broken.

I think that especially for noobs, Juliaup is the best choice, if it can be improved with adding a gui on top of It, It would be great.

But what I understood from the question (and I don’t know if I was the one to read it wrong or not) was a critic against Julia strongly recommending Juliaup as installer and manager of the Julia installations

1 Like
17

I do see the merits of your argument and have various agreements/disagreements on the facts, but I’ll just give the big picture: I think you are ultimately wrong about Julia-via-juliaup being more technical or difficult for “noobs”. I think I’m still a “noob” in most respects, certainly when it concerns handling different versions of a language and its packages in environments, and I will say that juliaup in combination with Pkg is the easiest experience I’ve had. To be fair, my experience is very obviously different from yours in that I’m not manually linking paths to Julia. But in my opinion, that IS more advanced; the most I want to type outside of Julia code is julia, its version, and an environment, which juliaup lets me do out of the box. Manually downloading separate Julia versions is a nightmare to me by comparison. juliaup may very well make some things more difficult, and maybe it can be improved or its usage can be documented better, but outright removing its recommendation seems like a step backwards for “noobs.”

What do you mean by this exactly? It sounds like a version control system, which I wouldn’t have Julia handle, but I’m not sure.

19

Besides the automatic updates and the ability to easily run old versions in projects—two extremely good and compelling reasons—here are four other reasons for juliaup to have become the standard, recommended way to install Julia.

  1. People want to do apt-get install julia or brew install julia and use their distro package manager to install Julia. Unfortunately, distros seem mostly incapable of packaging Julia in a way that isn’t deeply broken. There’s a few notable exceptions, but this is pretty broadly true. Packaging juliaup (and maybe even calling the package “julia”) is very straightforward, however, and allows the distro to package something small and easy, which then installs and manages official Julia binaries correctly. End-users get the installation experience they want and still get non-broken Julia. This need to be done on various distros, but having juliaup as the standard way to install is a prerequisite.

  2. In the near future, if you activate a project and start Julia via juliaup, it will use the julia version indicated in the manifest automatically, which means that the whole bit about using old Julia versions in old projects to ensure they keep working exactly as they did before will be even more powerful and convenient—and will also become something that non-power users get automatically without having to do anything fancy. But this only works if they are using juliaup.

  3. Every alternative way of installing Julia has enormous development cost. It takes a huge amount of effort and time to develop, maintain, and test an installation system. So much effort. If you have not done this for software that is used and installed by hundreds of thousands of people on all different snowflakes of systems around the world, it’s hard to convey just how difficult it is to make it work smoothly most of the time. We do not want to double this effort. Or triple it. We want to focus on one standard way of installing that is really good and make it work really well for everyone everywhere.

  4. Every alternative way of installing Julia also has enormous user experience cost. Aside from higher development cost making each individual way of installing Julia less good, merely having more options makes things more confusing for users. “Yikes, there are three different ways to install Julia on my platform! Which one do I do? This tutorial tells me one thing but this blog post does another one. Eh, never mind…”

I do think we could have more native ways of installing juliaup: a Wizard on Windows, App Store on MacOS. And native GUIs to interact with juliaup are also a good idea. But having it be the standard way to install and manage Julia versions is a necessary prelude to that happening.

44 Likes
20

There’s apparently a bug in juliaup which causes old versions to hang around and become unreachable for gc on Windows: [WINDOWS] Failed to delete old version, gc does nothing · Issue #1153 · JuliaLang/juliaup · GitHub

I’ve had this problem, with ancient versions hanging around for years, without me noticing. In the end I had to remove them manually. But hopefully, this can be fixed now that the likely bug has been identified.

As for juliaup in general, I find it much easier to just set my paths to julia+release and julia+beta, etc, and leave juliaup to manage the rest.

6 Likes
21

This is, of course, the best response and devoid of any polemics. You are the voice of reason.

I never proposed using the distros’ package managers. Often out of date and often don’t meet the requirements of the system being installed. It is best to have Julia itself take the responsibility for initial installation and absolutely to use Pkg and/or the package REPL for installation and management of packages.

I never mentioned a GUI. If all the GUI does is install and the only choice is to install (or maybe also uninstall, perhaps more usefully) then it’s a GUI with one or two buttons. Definitely pointless.

Your points 3 and 4 are the most compelling because somebody has to do the work and that means you and other maintainers.

Let’s say you chose to eliminate all the other methods of installing Julia: no .dmg for MacOS, no Windows store item for Julia, and strongly recommend against distro package managers and homebrew. Cool. Then, all I’d suggest is the following:

  1. don’t use juliaup as an intermediary path. It can mess with other external tools. But, the various binaries for different versions directly under ~/.juia. I realize juliaup is doing nice thing by allowing a choice to be made using the juliaup command and then running Julia by typing julia. Seems like that might be done by manipulating the path set to Julia “under the hood” of the OS.
  2. Make juliaup itself a bit easier to install. It’s an executable binary so it has to be built for each platform. Just have the pre-built binaries for “popular” platforms (YMMV) and it’s just download and run. It’s close already. Sure, you can enable build it yourself, but since it’s in Rust not everyone will be facile or have the Rust toolchain installed to do that.
  3. Juliaup is actually a pretty complicated tool because of all the possibilities it must address, so some super simple defaults (which may already exist) for the noob community would be an objective improvement over .dmg, et al.

If 1 and 2 were true then I have no case. Currently, the best of both worlds satisfies everyone, but at a cost in effort that would be reduced by only having one method. (BTW: no overriding reason to satisfy my request, which was really only a documentation suggestion.)

Unrelated extra credit: a simpler way to migrate packages. This could be a Julia script and the community could do it.