I use juliaup myself, and I fully agree with @VivMendes.
Basically, when one only needs one Julia version installed/available, and doesn’t know command line, the so-called “manual” installer is unambiguously easier to use. On Windows and MacOS, it behaves like a lot of other software users see, with standalone installers; on Linux, one kinda can assume the user knows CLI anyways.
The reason rustup can be “the” way to install Rust, but juliaup shouldn’t be “the” way to install Julia is simple – only developers need to install Rust, but Julia needs to be installed by users as well.
I haven’t followed recent changes to Julia installation page closely, but I always recommend the so-called “manual installers” to people who aren’t very used to CLI and don’t plan to write Julia code themselves; haven’t heard of installation issues.
People have had issues with the manual installers. Since juliaup is an added layer of moving parts on top of the manual installer, it has those same issues and bugs plus its own issues and bugs.
I am on Linux and really like using juliaup, but if it doesn’t work, I have a hard time figuring out why. Compare the readme of juliaup to jill: jill says exactly what the installer will do by default, while juliaup just says that it will somehow ensure a julia is on the PATH and that it will store some extra juliaup config files (this julia is not actually the julia exe but instead a rust binary, and I still don’t understand why I want these extra config files).
I personally am strongly against there being any mention of install methods different than juliaup. I have had the exact opposite experience compared to @VivMendes – I have had to debug many issues with the manual installs while juliaup has always been clean and issue free.
The Rust community specifically hides any mention of alternatives to rustup. It would be interesting to see (a) why that works for Rust and (b) why VivMendes have such diametrically opposed experiences.
One potential answer to (b) is that VivMendes just needs Pluto, while I expect my students to use an actual IDE and know how to install a package / use the terminal.
I think the term “standalone” is very confusing and may mislead newcomers to Julia more than elucidate. Without using juliaup, I can have as many Julia versions installed side-by-side on my computers as I wish (and I do). But this is another matter.
I have Julia installed on 3 Linux machines, and I did not use juliaup. There are many ways to install Julia on a Linux machine. There is the juliaup script, the Abel Siqueira jill script here, downloading the official tarball (either manually or via the terminal) and setting the path, and there are still others. We can install the versions where we want and manage them through the terminal, very, very easily. But this is not what I expect from my students (and most people who come into programming)! This is what better suits me, not all potential Julia users.
What does juliaup have to do with having the ability to use an actual IDE? Or use a terminal? If the VSCode Julia extension looks for the Julia path, it does (or should) not matter what script established that path.
It generally it has nothing to do with it, but this thread is about common mistakes that students with zero sys-admin skills make. Then it starts having a lot to do with it, as a minor misstep early on in setting up your system compounds and makes the next step impossible.
For you (VivMendes), I assume all the complexity is handled by Pluto, so basically there is no “next step”, so the simplest install is best (which for non-WSL Windows and Mac might be the manual install – I would argue that is not the case for base Windows and for Linux).
The failure mode that most of my students face is installing multiple separate julia installs, being unable to figure out how to install new versions or update, installing as root, messing up or forgetting PATH variables, downloading and extracting in an arbitrary place but not “installing”, modifying their system in a difficult-to-reverse fashion, and many more. All of these are stupid things a competent developer or a user would know not to do, but I do not think this conversation is about competent developers or users. In my practice, juliaup has been safer for folks without sysadmin skills.
Same reason people without sysadmin skills have always been directed to use conda (or now uv), instead of the download from python.org.
Quite a bit. IDEs need to be able to find the Julia executable. One approach to this is to add it to the path (eg preferred on Linux), another is to hardcode a fallback (eg try in Applications on OS X, AFAIK VS Code does this), yet another is to specify manually. This gets quite complicated if there are multiple versions, some implicit assumptions no longer hold. See eg
Yes, but it is unclear if that is a feature or not. It would be great to converge on a single installation mechanism, and at the moment it looks like that it will be juliaup. Though that has bugs to iron out, each bug report helps.
This of course does not prevent anyone from suggesting the “manual” method, which should (and will) remain available.
I’ve run into this juliaup bug that can cause crashes on HPC clusters due to failure to lock the config file, depending on the network filesystem setup: https://github.com/JuliaLang/juliaup/issues/435
When you do succeed in launching, say, a thousand julia processes, another annoyance is that the output log file begins with a thousand exact copies of the same message telling you that a new patch version of Julia is available for upgrade, as the julia launcher prints out the message before executing the user’s script.
There are reportedly workarounds for both problems by disabling the checking of updates, but it’s as easy, if not easier, to just use the bare Julia executable when submitting jobs. Now I use juliaup on login nodes for installation but supply the absolute path of the installed julia executable for non-interactive jobs.
I also avoid using juliaup when building Docker images for deploying my programs, since the julia version is frozen anyway. With the Julia website directing everyone to juliaup, some new users will never become aware how the bare installation works, which will be limiting for certain use cases.
Idk, can you elaborate? As I understand it, Jumbo is an opinionated set of packages, with fixed package and Julia version.
It can be fine for trying out Julia, but how would it help “non-developer users”? In that scenario, you are running someone else’s code, and want the versions of Julia and packages to match what the code author intended.
If you are teaching a course, you can set up your own set of packages the same way Jumbo does. Then it will be consistent within the course and easy to deploy. Of course, it won’t run arbitrary Julia code.
I don’t bother with juliaup; I don’t see the need for it. I also don’t use a plugin manager for neovim, for similar reasons: I don’t want to add layers of software to my processes unless they solve a real problem or significantly improve my workflow. These layers are extra opportunities for bugs, imcompatibilities, and mysterious behavior, and they obligate me to learn how to use them. They get in the way.
One thing I find terrible about the general “execute curl -fsSL https://<some-url> | sh to install our software” (and juliaup is just one instance of this) is the security hole this opens up, due to the impression this gives to users that downloading some unknown script from a URL and executing it locally without inspection is perfectly fine. The Julia installer does not use sudo, but I bet that if it did many users would simply enter their password when prompted for it, as they would assume it’s needed for the installation step. Getting used to such installation instructions is something malicious actors can take advantage of.
What is the difference between downloading some script from a known site like julialang.org vs downloading a binary from there and running it? Couldn’t both wreak havoc on your system if modified by some malicious actor? Can’t a binary prompt for a password to gain privileges? I’m not sure if the script is more dangerous in that way. On my Mac for example, for software where authors do not bother with notarization, they always trigger a security warning. So you go and disable that, and run them anyway because you trust that through the delivery mechanism of Github and the reputation of the source, you’re not in actual danger. But you don’t really check anything, similar to a julia binary, similar to a shell script. You can check checksums but if the julialang website starts serving a malicious shell script then whoever did that can also add a checksum to match for it I’d assume.
If a user runs their own script under Julia - after manually installing Julia by untarring somewhere - and it starts asking for a password it’s more likely they would become suspicious, compared to getting asked for a password during install-via-curl.
It’s not about the specific script being downloaded from, say, julialang.org. It’s just that the method of telling users to do curl .... | sh is more likely to lead to yet another attack vector (could be hacked julialang.org, or some malicious website trying to distribute malware via a legitimate-looking webpage via installation command).
Quick fix: make users aware on the download page that executing curl -fsSL https://<some-url> | sh should never ask for a password, and that in general Julia itself will not do so either.
