# Snap Package for Linux distribution

**URL:** https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583
**Category:** Internals & Design
**Tags:** proposal
**Created:** [March 10, 2017, 2:31am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583 "2017-03-10T02:31:41Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![TheLoneCodeman](https://avatars.discourse-cdn.com/v4/letter/t/e47c2d/32.png) [@TheLoneCodeman](https://discourse.julialang.org/u/TheLoneCodeman)
#### Post date: [March 10, 2017, 2:31am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/1 "2017-03-10T02:31:41Z")

</div>

Hi, so I have been using Julia for about 7-8 months now, and I have noticed that while there is a package for CentOS/RedHat/Fedora, I noticed that there is no longer an official julia apt package. Now, Ubuntu’s maker, Canonical, has been really pushing this new thing called Snaps. They are now universal across pretty much all the major Linux distributions. I was wondering if there was any talk about making an official Julia Snap package, then all Linux distro’s have a simple setup?

---

<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: [March 10, 2017, 9:02am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/2 "2017-03-10T09:02:00Z")

</div>

Yes, it’s been discussed recently [here](https://github.com/JuliaLang/julia/issues/14167), but no work has been done so far. The main issue is that only recent distributions support Snap or Flatpak, so we will still need to provide generic binary tarballs anyway. But a contribution to support Snap would certainly be appreciated (either as a community-maintained effort or even maybe as an official download). It appears that a simple way of creating a package would be to simply re-bundle the binary tarballs without even rebuilding Julia.

---

<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: [December 3, 2017, 8:53am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/3 "2017-12-03T08:53:27Z")

</div>

I have been wary of snap for a while (yet another damn update mechanism), but I have been using it for 3 months now and it is really seamless. Once you [authenticate](https://docs.snapcraft.io/core/usage), you no longer need to be root, and updating is really simple (`snap refresh`).

It is my impression that many FOSS projects that release more frequently than 3-6 months have decided that they need something in between tarballs (a bit too manual) and distro packages (high maintenance for all the distros out there) went with `snap`.

The only issue I can see for Julia is the [confinement model](https://docs.snapcraft.io/reference/confinement); which restricts file system access to `$HOME`. But if I understand correctly, there is a `classic` mode which would get around this globally (but it requires manual review from the snap organization), and in any case, the user can override this so maybe this is not much of a hassle.

---

<div class="post-metadata">

### Author: ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)
#### Post date: [January 28, 2019, 8:17am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/4 "2019-01-28T08:17:19Z")

</div>

Update:

A snap called `julia-stable` ([https://snapcraft.io/julia-stable](https://snapcraft.io/julia-stable)) is available. It’s sourced from: [https://git.fmind.me/fmind/snap-julia-stable](https://git.fmind.me/fmind/snap-julia-stable) and is just a dump of the official tar.gz file.  
The problem is that it’s not up-to-date (=1.0.0) and doesn’t carry the “right” name i.e `julia`.

@mortenpi has a similar snap in his repo ([GitHub - mortenpi/julia-snaps: Snap packages for Julia](https://github.com/mortenpi/julia-snaps)), which predates the above one but isn’t registered.

It would be really good if the Julia creators could take the existing snaps and turn them into an _official_ snap with bells and whistles (integration into CI/release process, utilizing multiple channels (LTS vs most current), …).

---

<div class="post-metadata">

### Author: ![Bernard\_GODARD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bernard_godard/32/4155_2.png) [@Bernard\_GODARD](https://discourse.julialang.org/u/Bernard_GODARD)
#### Post date: [January 29, 2019, 5:53pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/5 "2019-01-29T17:53:45Z")

</div>

I also think it would be good to have something like a snap, distribution agnostic and auto update from the repository. However, I would prefer flatpak. Snap is more of an Ubuntu thing that kinds of work in other distributions. But flatpak support is generally better in most distributions:

> **[Home | Flathub](https://flathub.org/)**
>
> Find and install hundreds of apps and games for Linux. Enjoy Firefox, Telegram, RetroArch, GIMP and many more!

> **[Flatpak—the future of application distribution](https://flatpak.org/)**
>
> The days of chasing multiple Linux distributions are over. Standalone apps for Linux are here!

Even on Ubuntu, I have replaced most of snaps by flatpak version of the apps. On Fedora, I have no problems with Flatpak but snap support was not so good.

However, there are still some issues regarding how to expose command line applications in flatpak:

> <https://github.com/flatpak/flatpak/issues/1188>
>
> From what I've read of the documentation there are 3 things that seem to be miss…ing for command line tools:
> \- Custom commands for running the app, having to do \`flatpak --run org.bla.bla\` every time seems tedious
> \- Providing autocomple for the command
> \- Providing man pages for the command

---

<div class="post-metadata">

### Author: ![aaowens](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aaowens/32/12101_2.png) [@aaowens](https://discourse.julialang.org/u/aaowens)
#### Post date: [January 29, 2019, 6:03pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/6 "2019-01-29T18:03:13Z")

</div>

I think the strict confinement model could actually be an advantage to a Julia snap for people concerned about all the issues discussed here: [Pkg: attack vectors](https://discourse.julialang.org/t/pkg-attack-vectors/18340) . Malicious packages might not be a major problem if Julia can’t see your home directory.

---

<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: [January 29, 2019, 8:17pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/7 "2019-01-29T20:17:03Z")

</div>

The major issue with Flatpak is the integration with Atom and VSCode, which currently can’t be got to work (see [this issue](https://github.com/flathub/io.atom.Atom/issues/8) and [this thread](https://lists.freedesktop.org/archives/flatpak/2018-June/001128.html)). But that doesn’t prevent creating a Julia Flatpak which is usable from the commandline. Users have to create a symlink manually, which is inconvenient but not the end of the world either.

I had made a [Flatpak for Julia 0.6](https://cloud.web.ined.fr/index.php/s/FZ8LUMb7ksDrcuf/download). If somebody wants to update it to 1.1 and publish it to FlatHub that would be useful. Most/all of the work should be updating the versions of dependencies.

---

<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: [January 30, 2019, 7:59am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/8 "2019-01-30T07:59:42Z")

</div>

> [@aaowens](#):
>
> Malicious packages might not be a major problem if Julia can’t see your home directory.

On most machines this would make Julia perfectly unusable, except for sending commands and receiving output via pipes.

I was enthusiastic about snap first, but I think that the installers/tarballs are now very convenient and impose much less of a maintenance burden (cf [install-julia](https://github.com/JuliaCI/install-julia)). I guess a snap/flatpak/etc package will be maintained when someone really wants to do it.

---

<div class="post-metadata">

### Author: ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)
#### Post date: [January 30, 2019, 2:01pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/9 "2019-01-30T14:01:40Z")

</div>

I’ve looked through the available programming related snaps (languages and IDEs): most of them use classic confinement mode.

> Snaps declaring their confinement as “classic”, have access to the rest of the system, as most legacy (debian packages for example) packaged apps do, while still benefiting from the ci-integrated store model, with automated updates, rollbacks to older versions, release channels, etc. (From [https://blog.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement](https://blog.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement))

With this the connection to atom shouldn’t be a problem.

Being able to use a OS supported installation/rollback method instead of manual scripts sounds compelling to me.

With all the talk about Julia should be easy for beginners e.g. by shielding them from understanding scoping, I wonder why it is never a problem for teachers to require the shell, tar, symbolic links and environment variables like PATH until you can start Julia.

---

<div class="post-metadata">

### Author: ![zyga](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zyga/32/8925_2.png) [@zyga](https://discourse.julialang.org/u/zyga)
#### Post date: [June 15, 2019, 5:25pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/10 "2019-06-15T17:25:40Z")

</div>

Julia is now a snap available in the snap store [Install julia on Linux | Snap Store](https://snapcraft.io/julia)

Currently the LTS track seems to be available only (1.0.4) but perhaps other versions will become available. I just installed Julia snap on my openSUSE system and it works fantastically. Thank you for everyone who made this possible.

---

<div class="post-metadata">

### Author: ![jeff.bezanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff.bezanson/32/48_2.png) [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)
#### Post date: [June 18, 2019, 4:57pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/11 "2019-06-18T16:57:43Z")

</div>

Yes, Alex Arslan (mostly) and I put that up last week. We are using “classic” confinement mode (so you can e.g. actually access files 🙂 ), which is what other languages seem to do. We eventually plan to provide “tracks” for different minor versions of julia, but snap wasn’t originally designed for programs with multiple user-selectable versions so doing that is not easy enough yet. I think it will get there though.

---

<div class="post-metadata">

### Author: ![jayschwa](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jayschwa/32/2640_2.png) [@jayschwa](https://discourse.julialang.org/u/jayschwa)
#### Post date: [November 11, 2019, 2:08am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/12 "2019-11-11T02:08:00Z")

</div>

Are any updates planned for the snap package? It’s still on v1.0.4.

---

<div class="post-metadata">

### Author: ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [November 11, 2019, 9:19am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/13 "2019-11-11T09:19:25Z")

</div>

Related to Snap, I have no idea how the installation process works, but I found a few people that installed 32-bit version of Snap Julia on 64-bit systems, causing troubles with binary dependencies.

---

<div class="post-metadata">

### Author: ![heliosdrm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/heliosdrm/32/3851_2.png) [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [November 11, 2019, 10:52am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/14 "2019-11-11T10:52:41Z")

</div>

That snap release was published half a year after Julia 1.1 was available, so I assume that the publisher intended to provide the LTS version, not the latest stable version.

v1.0.4 is still one patch behind the latest LTS version, so it could be updated indeed, but depending on what version you expected, it is not that far away.

---

<div class="post-metadata">

### Author: ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)
#### Post date: [November 11, 2019, 12:30pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/15 "2019-11-11T12:30:43Z")

</div>

@ararslan mentioned on Slack that it’s not yet decided if they want to support snap further on, as it incurs some overhead.  
I’d for one prefer snap over distributions trying to compile and build Julia on their own, so I’ve created a PR to update the snap to 1.0.5 ([https://github.com/JuliaCI/julia-snap/pull/4](https://github.com/JuliaCI/julia-snap/pull/4)).

Although the track request has already been posted a while ago: [Request for Julia tracks: 1.0, 1.1, 1.2, 1.3 - store-requests - snapcraft.io](https://forum.snapcraft.io/t/request-for-julia-tracks-1-0-1-1-1-2-1-3/11805) I think it would be less work to only have two _tracks_ ([Channels | Snapcraft documentation](https://snapcraft.io/docs/channels)): `lts` and `latest`.

---

<div class="post-metadata">

### Author: ![pontus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pontus/32/10438_2.png) [@pontus](https://discourse.julialang.org/u/pontus)
#### Post date: [November 11, 2019, 1:57pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/16 "2019-11-11T13:57:23Z")

</div>

Recently moved to linux (Manjaro/Arch) and needed to decide between Snap, official binaries, pacman…  
Noted the Snap wasn’t latest version, so went with pacman install which gave latest v1.2 Not sure if I would have had the Arpack build issues (described here [Resolved: Arpack deps.jl Linux build issue](https://discourse.julialang.org/t/resolved-arpack-deps-jl-linux-build-issue/30923)) with Snap or binaries.  
Another thing that is a bit confusing (or just new and something else to understand) is the appearance of all the “loops” in the form `/dev/loopXXX` in my mount list:

```julia
df -aTh | more 
Filesystem Type Size Used Avail Use% Mounted on
/dev/loop1 squashfs 55M 55M 0 100% /var/lib/snapd/snap/core18/1223
/dev/loop0 squashfs 43M 43M 0 100% /var/lib/snapd/snap/snap-store/201
/dev/loop3 squashfs 147M 147M 0 100% /var/lib/snapd/snap/slack/18
/dev/loop5 squashfs 55M 55M 0 100% /var/lib/snapd/snap/core18/1265
/dev/loop4 squashfs 20M 20M 0 100% /var/lib/snapd/snap/node/2494
/dev/loop2 squashfs 90M 90M 0 100% /var/lib/snapd/snap/core/7917
/dev/loop7 squashfs 8.2M 8.2M 0 100% /var/lib/snapd/snap/evince/214
/dev/loop11 squashfs 25M 25M 0 100% /var/lib/snapd/snap/heroku/3848
/dev/loop10 squashfs 23M 23M 0 100% /var/lib/snapd/snap/snapd/4992
/dev/loop12 squashfs 68M 68M 0 100% /var/lib/snapd/snap/sublime-text/77
/dev/loop13 squashfs 145M 145M 0 100% /var/lib/snapd/snap/slack/19
...

```

---

<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: [November 11, 2019, 3:19pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/17 "2019-11-11T15:19:29Z")

</div>

> [@pontus](#):
>
> needed to decide between Snap, official binaries, pacman…

If you are an Arch user, I assume that you are comfortable with the command line, so just `git clone`ing the repo and compiling the version you need is also an option.

---

<div class="post-metadata">

### Author: ![pontus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pontus/32/10438_2.png) [@pontus](https://discourse.julialang.org/u/pontus)
#### Post date: [November 11, 2019, 4:03pm UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/18 "2019-11-11T16:03:08Z")

</div>

Thanks for the input Tamas, appreciated. Haha, as comfortable as can be after 3wks, am wresting w/ keybinding conflict in `~/.zshrc` atm to get command history search to work properly.

Have sort of been avoiding use of Snap/Snapstore (hence interest in this thread) and current process with Julia or any other package is:

1. search if package is available via pacman using `sudo pacman -Ss <packagename>`; install if available; watch for dependencies, optional dependencies and install those as needed
2. if git repo avail, `git clone <gitlink>` into specific pkgtmp directory, take a look at the PKGBUILD file, then `makepkg -si`.
3. if above isn’t an option, try `Yay` and `Pamac` next.
4. if those don’t pan out, download a tarball using wget, `tar -xvzf <tarball>`, and go from there.

Looking at notes, it seems snapd and snap were different and was guided in arch forums to use snapd if I recall, notes:

```julia
  154 $ sudo pacman -S snapd
  155 $ sudo systemctl enable --now snapd.socket
  156: Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /usr/lib/systemd/system/snapd.socket.
  157 $ sudo ln -s /var/lib/snapd/snap /snap

```

---

<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: [November 12, 2019, 7:44am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/19 "2019-11-12T07:44:51Z")

</div>

In Ubuntu and Debian, my strategy is to use packaged solutions from the distribution repositories for 99% of software, and compile from source for the rest which is critical for me and has a rapid update cycle.

I think Julia is very well set up for just downloading/cloning the source, compiling it, and running from that directory without any “installation”. I find this much more convenient than any alternative.

---

<div class="post-metadata">

### Author: ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [November 12, 2019, 10:56am UTC](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583/20 "2019-11-12T10:56:50Z")

</div>

For stable version of Julia on Arch Linux I use [AUR (en) - julia-bin](https://aur.archlinux.org/packages/julia-bin/), which simply grabs the official Julia binary

[Next page](https://discourse.julialang.org/t/snap-package-for-linux-distribution/2583.md?page=2)
