Well, I don’t think mine is actually blocked, since it works intermittently. I’ve not noticed having two Julias. I installed first time (somehow) from the store, and update from winget.
Julia in msstore is juliaup.
winget currently shows software from two “catalogues”: a more or less free-for-all community repository, and every app from the Windows Store. The community repository is older, and we added the current non-juliaup installer to that back when it came out. At some later point they started to surface all the apps from the Windows Store, and now both the current default Julia installer and Juliaup show up there. My understanding is that the next version of
winget will automatically prioritize a Windows Store version, if it exists. We could presumably also remove the non-juliaup version at some point.
If there is any more detail you can provide how that manifests itself, please let us know as much as possible over at https://github.com/JuliaLang/juliaup!
Fyi, I have tried to install the one from the
msstoresource but bumped into an issue:
Verifying/Requesting package acquisition failed: no store account found
I think they are still working out how the MS account requirements from the store translate into the
It might be a good idea to specify for various platforms where Julia installations are installed and how they are named, and maybe how and where meta data is stored. This way people could manage or at least choose Julia installations with other tools. Then rustup would be designed to conform to this specification. Currently, it looks like each of the installation tools installs Julia in its own, idiosyncratic location.
juliaup does look pretty complicated compared to, say jill.py. And using rust is buying into some complexity and barrier to contributions. It’s worth it if high performance is a requirement, but that’s not the case here. Is the main reason juliaup is written in rust because rustup is? That said, a better choice for a strictly universal installer isn’t obvious to me. Maybe go. I can understand that rust has proven to be better than Julia itself and c++.
I wonder how often Julia is installed in a python-less system. Python has big advantages over rust. It is always installed on linux and macos. It can easily be installed on windows. But, admittedly, that’s (perhaps) not as easy as just going to the windows store. I looked briefly into building a stand-alone Python app for jill with pyinstaller. The resulting executable is 155MB. And the build feels fragile. Startup is a bit slow unless you build an app in a folder. It’s probably difficult at best to make anything close to as lean and fast as juliaup. I don’t see a clear path to a universal installer written in Python.
Still people install Julia for different reasons. I am interested in installing it to support Python projects that depend on Julia, in which case only jill.py makes sense. Partly because juliaup is not ready yet. But juliaup would have to be very convenient and easy to integrate with Python to convince me to use it. Maybe that will happen. There may be other reasons that make Python, or another tool, attractive.
Juliaup will install all Julia installations in
$JULIA_DEPOT_PATH/juliaup, which has the nice propery that all data related to Julia is inside one folder, alongside e.g. artifacts or compile caches.
Juliaup does have a bit of a history. I believe it was originally written in Julia itself and shipped using PackageCompiler.jl. This made the resulting binary quite large though and difficult to handle. It was then reimplemented in C++, but that has of course all the usual drawbacks when it comes to memory safety, portability and lack of convenient package management for external dependencies. At that point Juliaup still only supported Windows. David eventually decided to rewrite it in rust, which had the nice side effect that it made support for Mac and Linux much more feasible. (I think he mentioned it might have also been partly out of curiosity for the language.)
As an occasional contributor, I must say that rust has really nice tooling for these kind of CLI applications, especially the exception handling works quite well for this. The code is pretty well structured, so I don’t think the implementation is as intimidating as it’s made out to be in this thread. Go probably would have been an option as well, but I don’t think it has major advantages over rust for CLI application and I have heard it described as generally being more verbose than rust.
Juliaup consists of two binaries:
julialauncher gets exposed to end-users as
julia via a symlink on Linux/Mac and an execution alias on Windows. When a user installs Juliaup, and then types in
julia, that will actually start
julialauncher handles a few things: it handles the
+channel command line argument, reads the Juliaup configuration file, when in standalone mode occasionally checks for new versions of Juliaup itself, and then launches the correct actual Julia binary. As it essentially injects itself into almost every Julia launch, it needs to be really fast. And small and self-contained, so that it can actually be fast. That means it can essentially be written in C, C++ or Rust (or maybe Go? Not familiar enough with it) in terms of mainstream languages. The original version was in C++, but that was painful because even very simple things seem often very complicated in C++, plus it was just a major pain to get simple functionality like downloading files, extracting archives etc. working. I started looking at Rust at the same time, and it really is fantastic for this kind of software.
juliaup itself was originally written in Julia, as @simeonschaub rightly pointed out, and then compiled with PackageCompiler.jl. But that was never really a smooth experience, for many reasons. The resulting binary distribution was gigantic (couple hundred MB), which really is not ideal for a simple small command line tool, startup latency was not fantastic (not horrible, but not great), compile times were really long and it was all just really rough. So then at some point, when I had already ported
julialauncher to Rust, I just ported the rest over as well. And I’m very, very happy with that choice Rust is fantastic for this kind of software, the tooling is excellent etc. All the things that make Rust very different from a dynamic language like Julia, e.g. static typing, very different error handling model etc, make it a complete non-starter for scientific code, but for something like Juliaup it is a really good match (much better than a dynamic language like Julia, IMO).
Just to be clear, Rust compiles standalone binaries, end-users don’t need Rust or anything related to Rust installed on their system to use Juliaup.
I think in general a default Julia installer should “just work”, without users having to install anything else first. Plus, Python setup on Windows is kind of mess, IMO… I really wouldn’t want the default Julia setup story to get entangled in that.
Apple will no longer bundle python (2 or 3) with MacOS: https://macmule.com/2022/01/29/macos-monterey-12-3-will-remove-python-2-7-usr-bin-python/
Having Python as an dependency for installing Julia would result in “ok, forget about Julia” for me. My main hope in using Julia is: no R and no Python anymore. Even as a dependency which I don’t have to touch, just install, I would hate it. I hate both, R+Python, already … as a recent story: just this weekend I had to install a new R package (bioconductor). I knew at the beginning it will be pain. Hours of hours to install some dependency which popped up during some steps. At the end, no success, because pandoc had to be a newer version than debian jessie provides for some font of type woff2. Nothing I could overcome but it was just enough for me. You know? It’s only about building the vignette(docs) of some package which failed after HOURS OF DEPENDENCIES… It ruined my weekend and now I refuse to solve the next step just because the weekend is already ruined, no, I decided to enjoy my last hours of this weekend.
For all who want to help now: no need, I can overcome any R problem for myself after decades of fighting R/bioconductor/CRAN.
The point is: R and Python are good for academics where time (at the beginning of the PHD) doesn’t matter and problems don’t emerge because you start vanilla.
But whenever you have to think about time and future maintainability you would NEVER choose R or Python. NEVER! Period.
Choosing rust for juliaup is not a problem at all. It’s providing a small executable for all major platforms. That’s a good reason and a good choice. Contributing by learning rust is a no-brainer.
I would be in heaven of software development, if Julia itself could provide this feature of small executables (as I am not getting tired to say that).
Will a Windows installer still be available? I’ve never had a problem with using the installer and don’t really like the Windows Store.
@Lilith You might want to correct your table: juliaup doesn’t have Rust as a dependency (for the user) and it can also coexist with manual installs (that’s how I’m using it right now).
I want this too. I like juliaup, but more often I need the standalone installer. juliaup is for me the tool for installing Julia as a windows integrated (no PATH e.g.) Julia. But whenever I want to experiment with something I install a second Julia from the windows installer (without any integration).
This is my Windows Start menu:
Only 1.7.1 is per juliaup
Well, it needs some cleaning I guess.
I really like winget, which means I don’t have to struggle with the Store anymore.
You can switch between Julia versions with Juliaup too.
I’m not sure what this means.
I mean, I don’t want any integration into my OS, like setting PATH variables or whatever is needed.
So, for me, despite knowing about juliaup’s features, I like to have a single juliaup version installed (which I can run with
julia without setting the PATH variable, because it’s using a specific windows folder) and several other Julia versions which are just some folders somewhere without the OS bothering about it (except for deinstalling using windows app configuration).
Perhaps it’s just something about the “feeling of control”, but whatever it is, I prefer things I like, instead of things, I don’t like. Being rational into extremes isn’t rational.
To clarify a bit: I knew of, but only alluded to, the implementation language history of juliaup. rust is clearly the winner there, especially since the (volunteer) developers are very enthusiastic about the choice. There may be some people who think that a standard installer should be written in Python. Just to avoid sowing doubt among people who haven’t looked into this: I am not one of those. Especially after what has come out in this topic, I am 100% behind the current implementation of juliaup in rust.
To reiterate, there was still some confusion here between jill.py and the shell-script jill. They are essentially unrelated, sharing only a name. jill.py is much more capable.
The LOC in jill.py and juliaup are comparable. jill.py might even have more if it was brought up to feature parity. (The fast multiplexer is impossible)
I agree strongly that the multiplexer feature requires a very fast executable if
julia is linked to the
julialauncher. But, I think having the option to simply organize and check versions and download and install, rather than launch, is useful. E.g. I want my daily driver to load a custom system image, and maybe I want it to be called
julia. As far as I can tell, simply deleting the
julia symlink (in linux) to julialauncher is enough to get this. I imagine custom system images, etc. might be added later to juliaup.
Apropos, it was mentioned that “rust?” should be removed as a dependency in the matrix in the original post. This is a crucial point in understanding the choices.
Ok. That’s a big deal, and makes Python somewhat less attractive even as an alternative.
That is also my fervent hope. But, R is irrelevant here. And using Python to install Julia is only tangentially related to Julia competing with Python. The only reason I am interested in installing Julia from Python is to make it easier to integrate Julia into Python projects. It’s to promote Julia, not Python. At the moment, I have to use jill.py and it works well. But, maybe it can be replaced by juliaup in the future.
BTW: I find the experience with portable Julia superior to the alternative (installer)! Especially in combination with a custom depot. See Portable Julia - #16 by PetrKryslUCSD
Edit: try it with Julia 1.7.1.
@carstenbauer Thanks! I’ve removed “rust?” pardon my ignorance that rust compiles to standalone executables.
According to the juliaup readme, “On all platforms it is recommended that you first uninstall any previous Julia versions and undo any modifications you might have made to put
Julia on the
PATH before you install Julia with the installer in this repository.” I’ve opened an issue requesting that the behavior you utilize be officially supported, but until then, I think it is appropriate to leave a no in that row.
Perhaps this is a silly question, but are we reinventing the wheel by writing our own multiplexer in rust instead of using the operating system’s default behavior via symlinks and path environment variables?
For example, on my machine I have julia-1.6.4, julia-1.6.5, julia-1.7.1, julia-1.7.2, etc. and have julia symlinked to julia-1.7.2, julia-1.7 symlinked to 1.7.2, 1.6 symlinked to 1.6.5, etc. I can easily change my default julia with
ln, as well as configure my ide to run a specific version regardless of the systemwide defaults.
stop thinking in Linux, although I only use Linux, but if you want Julia to be universally accessible reinventing some wheels is no big deal, it’s not like we’re going to pile on top of
juliaup and having breaking release every month, it’s just an end users’ tool, the less assumption we make (by reinventing the wheel), the more control we have over the system that we can ensure it works on all platforms
Not a silly question. But, I think symlinks and environment variables are kind of a mess to work with. People (eg linux distros) tend to write utils with APIs to manage them. And the multiplexer is already written. Having a single API is great for help/documentation/cognitive load. Otherwise each platform must have it’s own recipe. And nothing precludes you from ignoring the launcher and rolling your own system.
I think “recommended that you first uninstall” is to avoid problems for the uninitiated. I found that you can easily delete a link, and edit your PATH and get what you want. So in a practical sense, it already plays with other installations. I haven’t really used juliaup, rather only used it while testing different installation methods. So far, updates and queries have not silently clobbered my modifications.