Snap Package for Linux distribution

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:
https://flathub.org/home
https://flatpak.org/

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:

1 Like

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 . Malicious packages might not be a major problem if Julia can’t see your home directory.

The major issue with Flatpak is the integration with Atom and VSCode, which currently can’t be got to work (see this issue and this thread). 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. 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.

2 Likes

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). I guess a snap/flatpak/etc package will be maintained when someone really wants to do it.

1 Like

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)

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.

Julia is now a snap available in the 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.

6 Likes

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 :slight_smile: ), 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.

4 Likes

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

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.

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.

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

Although the track request has already been posted a while ago: 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 (https://snapcraft.io/docs/channels): lts and latest.

1 Like

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) 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:

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

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

2 Likes

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:

  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

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.

3 Likes

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

1 Like

It might be the case the tools in the jlenv help?

The tools there are aimed at building, installing and managing the usage of several versions of Julia on the one system.

These build on the code, hence the experience, of rbenv and pyenv tools.

The chef cookbook is for slower moving targets where there are audibility requirements around Julia’s installation and usage.

Hope that helps?

If somebody is still interested in snap for more recent julia version, I’ve created a snap for current stable 1.3.1. It is named julia-mrcinv and is built from this snapcraft config. The name of the executable is julia-mrcinv but it can be linked to julia by putting snap run julia-mrcinv into a script or using alias.

I do that too, but on my previous laptop that was not feasible due to hard drive limitations imposed by my employer. Also students often find themselves in a situation in which ther computer environment is constrained in various ways, making compilation and certain ways of installing software difficult.

This post was temporarily hidden by the community for possibly being off-topic, inappropriate, or spammy.