Julia pre installed in Linux distro like python

Offtopic
1

Python is pre installed in many Linux distro. Why anyone is not shipping a Linux distro with Julia pre-installed ? or replace python or more like Linux distro with everything made in python replaced with Julia+mousetrap.jl

2

Probably because Python is a dependency of hundreds of packages that people use every day on Linux and Julia on the other hand … well, you’ll install it anyway if you already know that you want to use it and otherwise there’s no reason to have it installed by default for the vast majority of Linux users.

But you’d ultimately have to ask the people in charge of those decisions at whatever your Linux distro of choice is, I guess.

9 Likes
3

In the very old days, when data science was simply known as Statistics, Python was just a general-purpose language and was mainly used as a scripting language for Linux. That’s why Python is included in Linux distributions. Julia, on the other hand, wasn’t created for scripting. The reason we now compare these two languages side by side is because of data science and machine learning (of course the subject of scientific computation). In short, I don’t see any reason for Julia to come pre-installed on Linux distributions at this time.

10 Likes
4

It might happen with time, though is not needed (also people wouldn’t be able to rely on it for “Linux” until more than one, maybe many Linux distros would have preinstalled). You might be interested in: [ANN] AppBundler.jl - Bundle Your Julia GUI Application

Linux and other operating systems need Python for itself, i.e. some scripts (historically done differently, with bash or perl or awk etc.), but having such an option is mostly important for one language, they default to, and that’s it has fast startup for scripts, i.e. are NOT compiled at runtime like with Julia (though Julia also has an interpreter option, it’s just slower than Python, while it’s startup relatively fast).

Historically Linux/Unix has included many shells such as bash, and perl, and by now python, but not not all Linux do, e.g. Arch doesn’t have python (by default, it had Python 2, i.e. up to 2.5.1 seemingly only, then yes, Python3 now available but NOT preinstalled). You can still make Python apps for Arch, without it preinstalled, I don’t know how you do it exactly, your app install just needs to install Python too as one of its dependencies, and Julia could it the same way too. It’s though a bit annoying how many ways there are to install in different Linux distros, and it would be nice to know of one way that works on all, e.g. used the Ubuntu Julia snap where available by installing it for you, and differently elsewhere.

You do have Julia available as a snap, e.g. for Ubuntu: Install julia on Linux | Snap Store but yes you need to install it. [And I would rather want that the julia snap (and/or not yet available snap juliaup) would install juliaup, not julia directly.]

You CAN install the Julia snap on Arch and Fedora, but there you can’t rely on snap itself (i.e. snapd) so you you first need to install snapd. On Linux Mint, that I use it doesn’t have snap, and decided against it, while there’s a workaround to enable it:

https://snapcraft.io/docs/installing-snap-on-linux-mint

You also do have latest Julia available directly in Arch to install with this (without snap):

https://aur.archlinux.org/packages/julia-bin

For some reasons it has some dependencies such as:

I’m not sure why, would like to know, and for LLVM, Julia has historically bundled it’s own (making it larger, also because they patch it), I wouldn’t truest distros to bundle Julia if not exactly the same e.g. switching out LLVM for some other version of it.

1 Like
5

And then there’s also the fact that it is officially discouraged to even install Julia from your Distro’s package manager in the first place, the reasoning behind which I personally find a little odd (unless they are referring to some very obscure niche distributions)

Hardly a good argument for having something pre-installed if this distribution method is basically frowned upon by the Julia developers.

4 Likes
6

Installing Julia on Linux is trivial:

Copy and past the following line to install julia:

curl -fsSL https://install.julialang.org | sh

Restart your terminal, and then execute:

juliaup add 1.10
juliaup update

But I agree, having juliaup pre-installed would be nice, because piping a script using curl into your shell might be a security risk, and it looks cryptic.

5 Likes
7

Installing the package that your distribution has already prepared for you (there’s official Julia packages on Fedora, openSUSE, Arch and other popular distributions as far as I’m aware) and having it updated automatically is even more convenient, don’t you think? :wink:

Personally I find it very annoying whenever I have to install software on Linux in a non-standard way by downloading a script or whatever and have a program exist somewhere on my PC outside of the managed package ecosystem, that I then have to manually update etc.

And I think lots of Linux users feel uncomfortable doing that in general. I will bite my tongue occasionally whenever non-free software or software with “problematic” licensing is involved, but that’s not the case for Julia, so I think package maintainers should be encouraged to keep the packages up-to-date instead of promoting installing software like it’s the 90s.

3 Likes
8

Well, juliaup is the best way to manage Julia installations. And yes, you might need different versions installed at the same time, because different SW projects might require different versions. Julia is a fast moving target. And if you write SW yourself you want to test it with the next, upcoming version.

I don’t think that Linux package managers are good in managing multiple versions of a software on the same computer.

OK, having a dummy package julia-1.10 that just executes juliaup add 1.10 juliaup default 1.10 might be nice. Who is going to write one for Ubuntu/Debian?

3 Likes
9

Agreed, though sometimes you might really want to have Julia installed system-wide and not only in the user’s home directory. I suppose, as long as the Julia ecosystem is all about libraries/packages that are managed and installed within Julia itself, that’s an acceptable way of handling things. If there were ever to emerge any stand-alone applications that would preferably be distributed through Linux package mangers and relied on Julia being present on the user’s PC, things might get a little more complicated

2 Likes
10

I think it would be fantastic if say sudo apt install julia would install Juliaup. It would put julia and juliaup on your PATH and then everything would just work.

On Windows we pretty much have that situation: winget install julia -s msstore installs Juliaup.

The only caveat is that it is not clear to me how easy it would be to keep such a “apt” deployed version of Juliaup recent. At the moment we release new Juliaup versions every couple of weeks, and it is not clear to me how that meshes with the typical update policies that say Debian has.

5 Likes
11

A first step would be to create an unofficial julia ppa, see Personal Package Archives : Ubuntu . If that works, we could try to figure out how to automate the package creation such that a new version is always created as soon as you release a new juliaup version. A third step could be to extend this for other distributions.

The Launchpad help says: " Note: We do not allow uploading pre-built binary packages." @davidanthoff But building juliaup from source should not be too difficult, or what do you think?

12

Yeah, the persistent challenges are that distros have their own sets of policies, their own release timelines, and someone needs to navigate that and do the work of the packaging.

The policies can restrict how programs are built (e.g., ensuring dynamic linking to libraries or using their own build systems) and how programs behave (e.g., ensuring configuration files meet some criteria). I’m not sure if all distros would be happy to accept a juliaup package — it’s a shim that downloads unknown (to them) binary blobs and manages versions when they want their package manager to do that managing! For example, rustup is not packaged but rustc is.

Historically, these policies have sometimes resulted in broken Julias because, for example, they might have dynamically linked to a shared (and unpatched!) LLVM instead of using the Julia-provided one. So that’s why it’s not a recommended install path.

5 Likes
13

Well, from my point of view it would already be a progress to have an Ubuntu ppa. Start small, see if it works, gain some experience, and then - perhaps - expand.

14

Dealing with binary dependencies is complicated, we often find bugs in upstream projects which break Julia functionalities (last one was OpenBLAS, just this week). As a matter of fact, Julia needs a patched version of LLVM (Julia heavily relies on this compiler framework, being a compiler itself) and LibUV, in addition to very specific (but mostly unpatched) versions of some of the other dependencies. This is at odds with most Linux distros, which typically want to maintain a single version of a package at a time and don’t bother applying patches needed by smaller projects, and can’t deal with different packages having different and sometimes conflicting requirements, with the result that they need to compromise functionality of some of them. BTW, the not-so-niche Debian and Ubuntu stopped entirely shipping Julia a while ago, because of these difficulties.

6 Likes
15

Well, but my suggestion was to package juliaup and not Julia. This should solve all these issues, or not?

1 Like
16

I wasn’t replying to you, I was replying to someone else explaining the motivation of the notice on the website.

Yes, but I wasn’t commenting on that. Note however that Linux distros didn’t use to support packages which install other packages as they want to control everything (except, they can’t), I don’t know what are the policies nowadays but trying to convince some of them to install juliaup may not be super easy (I see Debian and Archlinux nowadays provide rustup, so maybe they’d be somewhat open to juliaup as well).

2 Likes
17

We might have strayed a bit from the original question why Julia doesn’t come pre-installed with most Linux distributions (as opposed to the more glaring issue why it isn’t packaged at all on some) - I hope this is ok? But I think the question of how Julia will be distributed on Linux in the future is an interesting one.

There was also a discussion ongoing recently about the future of the Julia package on Fedora (which is indeed quite outdated at the moment). And I think all of the challenges you mentioned are all apparent there and have also been raised by the current package maintainer.

I really wouldn’t want the flatpak route to become the way to go in the future, so packaging juliaup would probably be a more desirable solution long term. However, I also share the concerns about whether that would be in accordance with most distro’s packaging guidelines (i.e. not pulling pre-compiled binary blobs from somewhere)

As a side note, just out of curiosity: I’m not in the loop about the extent to which patching is needed on LLVM (nor technically inclined enough to understand, I guess), but is maintaining a seperate fork of LLVM with patches applied specifically for building Julia really the way to move forward? Sounds to me (naively spoken) like it would make more sense to get those patches merged upstream somehow than to fragment the llvm ecosystem with such customizations?

2 Likes
18

Arch AUR provides juliaup:
https://aur.archlinux.org/packages/juliaup
I find it slightly amusing that the juliaup binary is in /usr while the launched julia binary is in $HOME, but it works.

1 Like
19

Oh, that is encouraging! They probably also all provide things like Python? And Python has a package manger that presumably installs binaries? But agreed with everyone here: this will probably require a lot of delicate convincing :wink:

Also agreed with @ufechner7 that we should start with the ppa stuff, ideally just build and publish those as part of the regular Juliaup release process. Juliaup is a very standard Rust project, so presumably that should be quite simple.

20

Yes, but they also provide tons of python packages in their repositories, in principle you’re supposed to install those, in practice good luck being able to use that single version of a package if you have multiple environments with conflicting requirements.

3 Likes