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 know.
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.
3 Likes
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.
1 Like
@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
10 Likes
-
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.
3 Likes
Yes, that is correct. I just don’t want to deal with support requests when folks end up having two julia things on their PATH 
But as long as someone sorts that out properly, it should all just work fine.
4 Likes
I don’t think the dispatcher julia from juliaup is identical to using symlinks. There might be a super useful feature in the near future where, if the project is known at startup time, you can dispatch to the appropriate (compatible) julia version. This is from my point of view a killer feature that you just cannot mimic with symlinks.
1 Like
Might make sense to have an “Advanced installation” section that explains what someone who is comfortable with more manual stuff can do.
4 Likes
It’s not easy to get a good Python distribution through the windows store. It’s so hard these days that most people just use WSL. WSL is essentially the answer to how much Python does not work on Windows. Python on Windows is very fundamentally broken in many ways that it just does not seem like a good idea to keep going that direction.
1 Like
Just to be clear, by “not as easy as just going to the windows store” I meant that installing juliaup from the windows store might be easier than installing Python and then jill.py. I’m surprised to learn that it’s worse than I thought, that Python is so hard to install on windows. I just saw that even Microsost recommends Python on WSL as the preferred method! This is a long way from the old days, when they dismissed Linux as an unsecure, buggy, communist plot (for real). I guess that conditioning on a user wanting to install Julia increases the probability that the user already has Python installed. Notwithstanding, I’m hearing that the answer to “how often Julia is installed in a python-less system” is “likely pretty often”. In any case, I think exploring calling out to juliaup (as it improves) from Python tools such as find_julia is a good idea.
1 Like
I’m convinced that WSL only exists because Python got popular and works so poorly on Windows.
3 Likes
Regarding the table in the OP, I would like to suggest, to remove “known bugs” and “(with bugs)” in the juliaup column (only column where it occurs).
This emphasizing seems to imply that the other alternatives don’t have bugs, which I doubt. (without research, just as a general doubt).
And even the fact, that juliaup does have known bugs, isn’t anything which is of special interest in this case, when asking for experience on the different alternatives.
The whole python thing here is also derailing the discussion. As already said:
and so is python. Just because there is something written in python doesn’t make python relevant in the question of version managers for julia in a general sense.
For me, to answer the OP: I don’t have any need for a version manager for julia. juliaup is the only convenience tool I have used so far, and I don’t need it, but I understand that it makes it easier for some people. Important for me is, that I always have a source, from where I can install on my own on any OS on my own full control without any OS integration. This is quite the opposite from a version manager, it’s more like: can I skip any version manager. If not, that’s a problem.
is the gold standard for me (but I don’t use it as I am happy enough with the windows installer from the official julialang web site).
3 Likes
Can you have with juliaup several versions at the same time so that on one terminal you are using, say, julia1.0, and in another julia1.7? (that’s what I am using with symlinks)
Yes. The different versions are called “channels”. I think many people in this thread have a misunderstanding of how juliaup works, so I’m going to post the link again
4 Likes
And just to be explicit here, you can also have different symlinks for different channels (i.e. versions), yes.