Julia on Ubuntu Xenial


I got a new Ubuntu Xenial (16.04) workstation at my new job.
I absolutely know it is recommended to download Julia from julialang.org , however out of curiosity I used apt-get to install the distro supplied Julia. Version 0.4.5
Again I realise Xenial dates from 2016 so this reflects the version.
I guess what I am saying is this might cause a lot of confusion when 0.7 and 1.0 comes along.

Even in Artful )17) the Julia version is 0.4.7
I can see this causing a lot of confusion when Julia 1.0 is released. Julia 0.4.7 is very deprecated.
Lik eit or not, many people will try to use the distro supplied versions. I can imagine that also in companies the distro supplied versions will be the onyl ones supported. Thsi is of course where JuliaPro comes in!

Is the Ubuntu maintainer on this discourse?


I am using Debian which also have an old version available through apt: 0.4.7-7+b3

What I did was to clone the Julia source using

$ git clone https://github.com/JuliaLang/julia.git

and then

 $   git checkout release-0.6

and then


This should build an executable “julia” in the subdirectory usr/bin

I then link this executable to a directory in my path like /usr/local/bin or /home/$USER/bin

And I am happily running

> julia
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: https://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.6.3-pre.0 (2017-12-18 07:11 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 93168a6826* (122 days old release-0.6)
|__/                   |  x86_64-linux-gnu

at the moment.

If you do not want to do this, you can try Juliapro and follow the relevant instructions.



I think @johnh is aware of that, he’s just pointing out that the existence of the out-of-date apt package may be confusing for newcomers.


Thankyou both for the reply.
I queried the Julia package, the maintainer is just reported as the Ubuntu-devel-discuss mailing list.
I wonder if this is one of these 'orphaned"packages with no maintainer. Do I hear “well colunteer then…”?


This is pretty much the same with all software, except for those Ubuntu packages which were updated with security patches. Software in 16.04 is by construction from before April 2016.

Maintainers of rapidly developing software now seem to prefer other ways of distribution, commonly snap. Having a Julia snap package would be great.


@Tamas_papp @tkoolen I agree. I am on the HPC side of things, and one of my frequent rants is about people who use the distro supplied versions of (say) openMPI (the parallel transport libraries) and then find they are woefully out of date. The technique in HPC is to deploy the vanilla OS, then to deploy highly up to date libraries like that on a shared filesystem, or the OS image, and the user puts them into the PATH using Modules.

Of course that is why containerisation is becoming more and more popular. I am a fan of Singularity
https://singularity.lbl.gov/ (note to self - a Singularity container with the latest Julia is a good thing)

Looking at snaps, this sounds an excellent idea.
I guess we are getting away from the concept of a monolithic ‘Operating System’ which has set versions of libraries, software packages, compilers etc. which ar einstalled via the all-powerful Administrative user.
OSes will be seen as a base platform which provides the metal (ie CPU, storage, netwwork) upon which the user decides to deploy applications. And this is good.


For those curious, this approach is using the environment modules. Usually I just dump the Julia binary distribution into /opt/julia/$VERSION and use a simple modulefile like this:

#%Module -*- tcl -*-

proc ModulesHelp { } {
  puts stderr "Julia, a high-performance language for technical computing (0.6.2)."

module-whatis "Julia, a high-performance language for technical computing (0.6.2)."

set            root      /opt/julia/0.6.2
prepend-path   PATH      $root/bin
prepend-path   MANPATH   $root/share/man

With one modulefile per version, it then is quite easy to switch between versions with the module switch command.

Once Pkg3 matures, it will also make sense to define environment modules for adding to the JULIA_DEPOT_PATH environment variable.


We should probably contact Debian and tell them that if they aren’t able to package 0.7/1.0, they’d better drop the julia package altogether. It’s expected that distribution packages lag behind upstream, but at least they should reflect the latest version available at the time when the distribution was released. It hasn’t made any sense to ship Julia 0.4.7 for a long time already.

EDIT: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839668


I agree with @traktofun Pkg3 and Modules are going to be fantastic together. I would buy a new hat now if I were you. (British reference to preparing for an upcoming wedding)


@nalimilan thnakyou. but look at this from the Debian ticket:
The situation regarding the lack of TLS support in Debian’s libgit2
package remains unchanged. The OpenSSL license is incompatible with
commonly used GPL versions. Although libgit2 has an OpenSSL license
exception, julia uses at least one other GPL-licensed library (FFTW)
without such an exception.

I already had a thread regarding package uploads failing from behind a corporate firewall. I think this is the same issue.


Given that there is no release date for v1.0 on the Julia side, I don’t see how Debian could commit to anything on this issue. The reasonable solution is to drop Julia.

I plan to make a stab at snap packaging v0.7 in a few weeks.


Actually the problem isn’t Julia, it’s libgit2 and OpenSSL. If Debian are not willing to apply the libgit2 patch we use to support MbedTLS before it’s merged and released upstream, they won’t be able to package 0.7 nor 1.0 anytime soon, whatever its release date.

That would be nice. I’ve recently prepared a Flatpak package, and by supporting these two formats we would provide a simple solution for users of most recent distributions.


Did you make it public yet? I would be interested in trying it.

I know little about these formats, but perhaps if we have Flatpak, snap would be redundant. Also, I have heard that Flatpak is easier to deploy, snap seems very Ubuntu-centric (and mostly pushed by Canonical).

The third format I would consider is AppImage, here is a comparison.


I’ve put it here, but it will probably change a bit before it’s ready:

Given that some distributions prefer Snap (mostly Ubuntu) and others Flatpak (Fedora), there’s probably room for both, though it would be nice to be able to support only one format. I’m not familiar with AppImage, but their comparison is clearly oriented even if it’s not unininteresting. The fragmentation of formats is really too bad…