Nixpkgs: Snap support

[alesguzik]

Currently, there's no way to either repackage or directly install software packaged in a snap and flatpak formats. Because apps packaged in this formats can run unmodified on all major Linux distributions, their popularity grows, and we seem to be missing out.

Flatpak apps can be installed on Alpine, Arch, Debian, Endless OS, Fedora, Gentoo, Mageia, openSUSE, Solus, and Ubuntu.

Snap apps can be installed on Arch, Debian, Fedora, Gentoo, Mint, Manjaro, OpenEmbedded/Yocto, openSUSE, OpenWrt, Solus, and Ubuntu.

Ideally, I'd wish we can do something like this

buildFlatpakPackage {
  src = fetchUrl {
    url = "https://git.gnome.org/browse/gnome-apps-nightly/plain/gnome-builder.flatpakref?h=stable
    sha="..."
  }
}

[matthewbauer]

We should be able to get flatpak and snap runtimes packaged and have NixOS modules I think. They don’t require anything.

On the packaging side it should be possible but maybe not as straightforward as you think. Nix packages are not easily relocatable- it needs to be installed in /nix/store/... and you can’t just move it to another directory. We’d need either provide our own chroot or see if snap/flatpak can provide one for us so that the paths still work in the package. I wonder if it’s easier to just tell users to install Nix and then install from the binary cache? The user friendliness isn’t quite there though.

[vyp]

It seems like snap and flatpak are very similar to nix/nixpkgs in their goals? I wonder what is the point of supporting snap and flatpak when you could just package the applications for nix itself? Are these containerization technologies? Because if not, my worry for the long run is eventually having reproducibility issues by letting a 'middle man' build a package, and therefore potentially being a waste of time to support anyway? 😬

[jpotier]

@vyp A way to answer your concern is: what can you do in the short term, when a very complicated software is available as a flatpak/snap but not in NixOS? (I'm thinking of you steam) Being able to pull a flatpak can help.

[alesguzik]

@vyp their goals are quite different. Their goal is to create distribution-agnostic packages, so "package the applications for nix itself" is the opposite of that. Also, unlike nix-packaged apps, snap and flatpak apps are sandboxed (chroot/cgroups/namespaces). As far as I understand snap/flatpak apps are designed to not be used as dependencies for other software - apps are self-contained, standalone and independent. In that regard, reproducibility is not more an issue than with other nix packages that fetch/use proprietary binary blobs.

[vyp]

@alesguzik That makes sense, thank you. My my first thoughts looking at their websites were that nix can already seem to do what they advertise, so I wasn't seeing much advantages, but I see now that the way nix would handle these, and a lot of the potential problems I was thinking about, could be sort of analogous to nix fetching binary applications (e.g. a lot of the unfree packages in nixpkgs), I think.

@jpotier Yes of course if flatpak/snap has a package for something that nix doesn't, it has an immediate advantage. The same could be theoretically true the other way, so the argument just comes down to what is currently available. But my point was less practical and more theoretically, what if these package formats don't work well with nix, and then in the end we would have been better off just packaging it with nix, i.e. long term solutions. Currently nix (and nixpkgs) does have a problem with manpower imo (not to say the current team isn't doing great, they are!), and will probably do so for a while at least, so nonetheless it's still a good point you bring up. :+1:

[etu]

@vyp One of the advantages that snap could bring is that for example Solus have done extensive work on making Steam work well on their OS. And now they started building a base-snap of Solus to be able to ship a Steam-snap that depends on the Solus base snap. And then all the work that Solus have done would benefit other distros. For sure it's possible to reproduce all the work, but I guess that that's a lot of work...

[abbradar]

Actually we can run any application which expects FHS-based hierarchy in FHS chrootenvs. Our Steam is implemented in this way and it's fairly straightforward. We also have steam-run and steam-run-native which allow you to easily run applications in FHS-like environment with libraries from Steam Runtime available. I imagine that out of the box or with little tweaks we can get vanilla Snap/Flatpak applications running -- depends on how exactly are they installed and what do they expect (I don't know much about them).

[yegortimoshenko]

Progress on flatpak is now tracked in https://github.com/NixOS/nixpkgs/issues/32807.

[xeji]

Flatpak support was just merged in #33371

[benley]

Has anyone started work on supporting Snap? I've run into a few things that more-or-less require it, like https://anbox.io/ so I'm finding myself interested again.

(aside: there is also progress on anbox itself in #42076)

[matthew-piziak]

Snap support is also required to run the Aether client.

[tbenst]

I just packaged Tusk.AppImage, and it was trivial (https://github.com/NixOS/nixpkgs/pull/66710). It seems like we could implement buildAppImagePackage now? Only need url and sha to fill in the derivation template from pull request that is also used by ~5 other AppImage packages. Seems needless to create a new nix pkg for each.

[razvan-flavius-panda]

Anyone working on implementing snap support under Nix / NixOS?

[saksmt]

Any progress on snap? It becomes more and more important since there are packages only available in snap and they are pretty much important: microk8s to start with...

[mkg20001]

IMO:

I think the end goal shouldn't be to be able to re-package software from snap to nix (because we'd be better off just using the standard nix building procedure, so pulling from a snap would be no more different than extracting files from a .deb and replicating the build process because everything would need a rebuild anways to account for the /nix/store prefix), but instead the goal should be to provide a snapd/flaptpak daemon that the user can use to pull apps from the stores.

If it becomes an issue that snapd/flatpak is too deterministic for the user, then re-packaging properly for nix is the only good option, everything else just would be a hack.

[pbogdan]

From when I last checked one big issue with snap is that it assumes to have a total control over the system it's running on including but probably not limited to ability to manage systemd services, dbus services, global configuration files under /etc which would make it very difficult to integrate with NixOS using the stock snapd daemon.

[saksmt]

From user point of view it is irrelevant if it is hack or not, it should just work and that's it.
But from dev point of view we probably should just be able to parse snap package and translate it as nix one to be able to control whats going on

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[tbenst]

Still important to me

[ptman]

Isn't flatpak supported? So this should be retitled to only be about snap.

[tbenst]

@ptman yes you are right