# Julia on Ubuntu Xenial

**URL:** <https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429>\
**Category:** General Usage\
**Created:** [April 19, 2018, 9:47am UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429 "2018-04-19T09:47:49Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [April 19, 2018, 9:47am UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/1 "2018-04-19T09:47:49Z")

</div>

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](http://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?

---

<div class="post-metadata">

**Author:** ![johann.spies](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johann.spies/32/8805_2.png) [@johann.spies](https://discourse.julialang.org/u/johann.spies)\
**Post date:** [April 19, 2018, 12:57pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/2 "2018-04-19T12:57:02Z")

</div>

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

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

```

and then

```julia
 $ git checkout release-0.6

```

and then

```julia
make

```

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
> 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.

Regards  
Johann

---

<div class="post-metadata">

**Author:** ![tkoolen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkoolen/32/1603_2.png) [@tkoolen](https://discourse.julialang.org/u/tkoolen)\
**Post date:** [April 19, 2018, 1:03pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/3 "2018-04-19T13:03:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [April 19, 2018, 1:14pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/4 "2018-04-19T13:14:28Z")

</div>

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…”?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 19, 2018, 1:40pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/5 "2018-04-19T13:40:15Z")

</div>

> [@tkoolen](#):
>
> the existence of the out-of-date apt package may be confusing for newcomers

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](https://snapcraft.io/). Having a Julia snap package would be great.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [April 19, 2018, 2:25pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/6 "2018-04-19T14:25:10Z")

</div>

@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/](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.

---

<div class="post-metadata">

**Author:** ![traktofon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/traktofon/32/591_2.png) [@traktofon](https://discourse.julialang.org/u/traktofon)\
**Post date:** [April 19, 2018, 4:04pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/7 "2018-04-19T16:04:40Z")

</div>

> [@johnh](#):
>
> and the user puts them into the PATH using Modules

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

```tcl
#%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.

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [April 20, 2018, 6:49am UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/8 "2018-04-20T06:49:07Z")

</div>

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](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839668)

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [April 20, 2018, 7:35am UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/9 "2018-04-20T07:35:37Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [April 20, 2018, 7:36am UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/10 "2018-04-20T07:36:46Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 20, 2018, 7:57am UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/11 "2018-04-20T07:57:09Z")

</div>

> [@nalimilan](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [April 20, 2018, 12:11pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/12 "2018-04-20T12:11:53Z")

</div>

> [@Tamas\_Papp](#):
>
> 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.

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.

> [@Tamas\_Papp](#):
>
> I plan to make a stab at snap packaging v0.7 in a few weeks.

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 20, 2018, 1:01pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/13 "2018-04-20T13:01:33Z")

</div>

> [@nalimilan](#):
>
> I’ve recently prepared a Flatpak package

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](https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison).

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [April 20, 2018, 1:29pm UTC](https://discourse.julialang.org/t/julia-on-ubuntu-xenial/10429/14 "2018-04-20T13:29:51Z")

</div>

I’ve put it here, but it will probably change a bit before it’s ready:  
[https://cloud.web.ined.fr/index.php/s/Anl8RJIrSdvspNo/download](https://cloud.web.ined.fr/index.php/s/Anl8RJIrSdvspNo/download)

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…