Snap support

[alesya-h]

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.

[alesya-h]

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

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

[lukateras]

Progress on flatpak is now tracked in #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 (#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.

[freeman42x]

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]

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

[stale]

I marked this as stale due to inactivity. → More info

[iavael]

@io12
2. Flatpak has PATH at ${installation_base}/export/bin per installation.
Also remember that there may be multiple installations (default for "system" is /var/lib/flatpak and for "user" is $XDG_DATA_DIR/flatpak), which are defined at /etc/flatpak/installations.d (https://docs.flatpak.org/en/latest/tips-and-tricks.html)

[io12]

Thanks @iavael.

Also, apparently Nix doesn't let build outputs hard link to dependencies (NixOS/nix#1272), so deduplication might be hard. It might be better to just rely on nix-store --optimize for now.

Also, I made a repo at https://github.com/io12/nix-flatpak. I think it mostly works, but it's really slow. It takes ~5 hours for me to install a Flatpak vs a few minutes without Nix. I'm not really sure why, maybe something about how fetchOstree is implemented? The build also hits the open file limit, but running ulimit -n unlimited before building fixes this.

[yawnt]

I took a bit of a different approach from @io12 (although big inspiration, thanks!!)

https://github.com/yawnt/declarative-nix-flatpak

seems to work and is quite fast. doesn't really much deal with dedup because if you update a runtime, all apps under that runtime are supposed to be compatible so you only ever need one copy of each "branch" (i think).

it's kinda a rough PoC but if there's some interest i'm happy to maybe clean it up?

[vividn]

Thanks @yawnt. I have interest. What would help me the most is a README detailing how to get this integrated with an existing NixOS configuration and then install some example flatpak using it.

[yawnt]

I've added a readme with a flake example, I don't want to hijack the discussion so if you have any other questions, please kindly open an issue :)

[pmarreck]

I couldn't get the majority of my Steam games to work in the "native" Steam install, but they all work fine via the flatpak (or at least, the same ones that are known to work fine on the Steam Deck or via Proton, now work fine on my NixOS install). That's how I found this thread.

I'm still holding out hope, though, and to that end I bind-mounted the expected flatpak location to the original "native" steam root 😊 (this also prevented me from having to re-download everything, although I could have just copied/moved...):

  # to get both flatpak steam and native steam to use the same install directory
  fileSystems."/home/pmarreck/.var/app/com.valvesoftware.Steam/.local/share/Steam" = {
    device = "/home/pmarreck/.local/share/Steam";
    options = [ "bind" ];
  };

[RyzeNGrind]

Hey everyone, fellow n00b here. I am looking to consider using either NixOS or Talos in order to reprovision and redeploy my microk8s home lab cluster.
I was wondering if there are any updates on Snap support as it seems to be a bottleneck in order for me to choose between NixOS or Talos as the base OS for the cluster. Based on my limited understanding of Nix to date, it seems Nix is well on its way to being an industry leader in declaratively configured and reproducible build environments but we still seem to be in progress on some major pain points.

I would like to contribute to building and testing microk8s snap support where possible as I am on the line between choosing to commit to NixOS or Talos as my base OS. It seems Nix can easily do what Talos does plus more. Thoughts?

[pmarreck]

@RyzeNGrind What do you need to/intend to install via snap/flatpak/appimage?

Note that all those solutions I just mentioned are comparatively weak attempts to solve the problem that Nix/NixOS solves definitively. So there is, fundamentally, a philosophical hurdle to surmount, as any Nix[OS] developer/believer will tell you that any energy spent on bringing better snap/flatpak/appimage compatibility is literally better spent figuring out how to get the relevant apps up natively on nixpkgs.

It would be like going to the Cadbury chocolate factory and asking when they will have better carob chip support. 😆 "Hey Elon, when will you come out with a car that has a gas generator? We still have a few use cases where gas is more plentiful than high voltage."

That all said, like I said recently, I'm currently using Steam via Flatpak. This is absolutely a less than ideal situation, but I was struggling with some games, and I unfortunately don't have the time to help track down the missing configurations that would make those work (context: I have a 17 month old kid. Kiss your freetime goodbye, in case you aren't a parent yet! I hear it gets easier "in a few years"... sigh) Since I now love NixOS AND games, I would absolutely be willing to help the devs responsible for the Steam derivation figure out any remaining hurdles as soon as I have the time (hmmm, is it possible to lend games to steam friends? I have... A LOT of games)... but I don't.

Note that the other advantage of figuring out how to get a given app up on Nix[OS] is that once it's up, it's quite possible that it will be up for good, since updates breaking unrelated things ::cough:: glibc, ssl ::cough:: is virtually non-existent (notable exceptions include: things like graphics drivers, which everything in the GUI has to share, or window managers, of which you can only run 1 at a time). Maybe that's why nixpkgs has (I think) the largest number of available Linux packages across all Linux distros- The stuff that breaks from updates in those other distros takes labor to fix, and that's (almost) completely eliminated labor here.

[RyzeNGrind]

@pmarreck thanks for the detailed Q/A Peter. I guess I should have lead with the motivations when asking my initial question so my bad for that, lol.

I'm currently running an arm64/amd64 hybrid kubernetes cluster in my homelab thanks to Ubuntu and Canonical's snapcraft microk8s snap. Since it minimizes a lot of overhead to run production ready k8s with minimal to zero ops I was planning to try running a similar micro kubernetes cluster but on NixOS instead.

I was able to use microk8s and Ubuntu to date to learn everything I needed to secure my career path into DevOps while attempting to solidify my skillset and play around developing personal projects.

I guess based on my current limited understanding of Nix, i can see how valuable a tool it will become as part of the dev toolchain and wanted to see how i could migrate my existing cluster or create a new baremetal m-k8s cluster based on Nix. Hope my comment provided the insight or clarity needed.

I guess my end goal is to have a zero-minimal ops k8s cluster out of my homelab for running my self hosted services and maybe exposing a few endpoints or services to the web for friends, family, school stuff, projects, etc.

[pmarreck]

@RyzeNGrind Well I can tell you a few things as a guy who's been messing with Nix[OS] for a few months now, to illustrate my perspective. I think your intuition about Nix is largely correct; that's why a lot of us came here, and additionally I think it's cool that you were drawn here as a devops person, because mastering Nix[OS] (or Guix, just to be fair) would be a powerful tool in your toolbox. One possible place to start seeing how K8s might fit into the Nix[OS] picture might be https://nixos.wiki/wiki/Kubernetes (note: I haven't personally messed with k8s on nix, just steering you there!).

A few things to keep your expectations realistic:

1. The learning curve is not flat, it's rather steep, and lots of things are (under)documented, so you may need to spend time on google, forums, or nix-focused chat channels (there's a discord, and a matrix, and other locations) to get what you need to get done or earn the understanding you seek.

2. That said, you will probably hit a magic moment on this incline where you have things basically working, you understand enough to at least get something working, and then this happens: OMG. EVERY. MACHINE. I. OWN. NEEDS. TO. RUN. THIS. OS. 😄 I've seen this happen in myself, I've seen others online realize the same thing... The sheer leverage you get with declarative deterministic trivially-rollback-able config, like being able to just push builds to any of your machines over the wire or being able to just reboot into a previous configuration if something gets borked, or just having separate projects that all have their own dependency hierarchies without conflicting with each other, it's huge. I had a drive go bad for example a couple months ago and thanks to having the essential files in my home directory backed up and my machine config checked into source control, I was back up and running in under 2 hours (and that's mostly because I had to rebuild the custom ZFS-on-root config that is documented here: https://openzfs.github.io/openzfs-docs/Getting%20Started/NixOS/Root%20on%20ZFS.html)

3. The Nix language. You can get by for a while barely understanding it and just copying/pasting other people's configs, but eventually you'll want to understand what's going on there. It's been summarized as "JSON with pure functions" but it's a bit more than that and has a few quirky things about it (one that comes to mind is that assigning a list to an attribute actually appends those values to the existing list value of the attribute; you have to assign an empty list to clear it); a good interactive guide I found online is here: https://nixcloud.io/tour/ and the nixos search page has an "options" section that lets you search for any config option: https://search.nixos.org/options?

4. The word "derivation" scared me for a while. Do you understand the concept of "lockfiles"? (used in node, ruby and elixir, among other stacks)? A derivation is basically a lockfile for a particular app/component. Instead of just expressing the names and/or versions of any dependencies, it computes the actual hashes of the relevant commits or binaries (which encompasses EVERYTHING that piece of software needs to run) and stores them in a file called a "derivation" (extension .drv). There, you can now move on. ;) Regarding writing your own derivations in nix-lang, for now just find other people's code for something similar and modify it as needed. Expect to experiment.

On the "everything I own needs to run NixOS" front, here's a guy who built his own home router using nixos and loves it: https://skogsbrus.xyz/blog/2022/06/12/router/

Here's someone who came up with a MicroVM scheme that seems to work great: https://github.com/astro/microvm.nix

Anyway, I think you'll like it and can make it work for you, just expect to wade into the deep end for a while.

Back to regarding snaps specifically, this discussion mentions how Spotify is only reliably distributed as a snap currently, and provides a link to a recipe for it which might be helpful: https://discourse.nixos.org/t/installing-a-snap-package/11468/2 (I have Spotify installed and can attest to the fact that it runs well!)

[Sepero]

The reason we need snapcraft (and flatpak) support is because there are more and more snap packages being added by developers every day. Nix does not have the human power to repackage and stay up to date with all the programs that developers are releasing as prepackaged

[bayazidbh]

At the very least, I think a simple option of with.flatpakPkg and with.snapPkg (or maybe services.flatpak.install = []; if we go with existing options) to install the flatpak and snap apps declaratively would be convenient.

I don't think it should be that hard either -- for flatpak, you can do flatpak list --app --columns=application and check for app IDs that are present / not present, install the ones not present, and remove the ones not declared in the config file. Installing specific version of flatpak apps declaratively should be as easy as providing the commit version.

Snaps are probably more challenging, because of the specific orders they may ask for install / uninstall. A user may install firefox through snap (maybe for testing) and then remove it -- the unusued snap dependencies that came with firefox would need to be uninstalled but it has to be done in order, which is a bit more complex.

I'm mostly a home-manager user, but an option to declaratively install flatpak, snap, and maybe even AppImages would be very convenient and useful.

[iavael]

@bayazidbh that approach implies that nix would manage flatpak/snap storage. But nix manages only it's own /nix/store. And anyway making nix change installed flatpak apps doesn't look very robust.

[bayazidbh]

@iavael

Well, my main desire is for a simple way to manage flatpak declaratively, having everything be done declaratively makes it very convenient for me.

But other than that, I was thinking of it more as a tentative support. I'd love to have Nix be able to use flatpak-build and have a way to automatically build flatpak apps instead of just installing them from flathub or other repo.

But for some apps, I'd probably not care and just want it to pull a binary from a repo -- just that the install process be declarative so I can put them inside my home-manager config.

Edit: Found someone who've made a module for declarative-flatpak, though not soon enough that I didn't spend a day trying to work out my own way of doing it (oh, well, I learned a lot at least).

[dnkmmr69420]

We already got flatpaks but now we need a way to install snaps.

[orangci]

Flatpaks are working.. how about snaps?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/enable-snap-and-install-snap-applications/32834/2

[io12]

I have an initial attempt at https://github.com/io12/nix-snapd. So far it works with most of the snaps I've been using for testing.

[io12]

I have an initial attempt at https://github.com/io12/nix-snapd. So far it works with most of the snaps I've been using for testing.

I think it's now in a state where it works really well. Lots of people in this thread mentioned wanting snap support because microk8s requires it, but microk8s seems like a very complicated snap that deploys multiple systemd services, expects FHS, but also expects the FHS to contain more entries in /etc than buildFHSEnvChroot creates, and also apparently expects /usr to be writable. It might be possible to improve buildFHSEnvChroot or create an ad-hoc version just for snap, and mount an overlayfs over /usr so that it's writable, but even after this there might be other compatibility issues. I think that if people need microk8s it should probably be packaged directly for NixOS so that it can have source patches to fix compatibility issues. Most other snaps work fine, though.

[Sepero]

A message from Nextcloud developers stating that they only support snaps in Ubuntu, and that using snaps in other distros has greater security vulnerabilities. This may be considered a warning.
https://github.com/nextcloud-snap/nextcloud-snap/wiki/Why-Ubuntu-is-the-only-supported-distro

[tuxflo]

@Sepero thanks for mentioning that. I didn't know that snap is such a Ubuntu focused thing. To be honest I don't really get the whole point of snaps if they are supposed to be just property executed on Ubuntu.
Still sad that some applications are only shipped as snap (I'm looking at you, microk8s).

[iavael]

@Sepero snapd on Ubuntu uses ubuntu-specific features of apparmor, that most other distros usually don't. And it overall tied to apparmor, that most distros don't have.

If you use nixos, I think you are shouldn't be bothered about running snaps without apparmor, because you don't use it to run any software on your computer anyway.

[io12]

I have a draft PR to add AppArmor support but I haven't gotten it fully working yet. nix-community/nix-snapd#2

[arbv]

@io12 Thank you! It is very important, as it complements GUI-oriented flatpaks nicely.

[sehe]

My usecase for snaps is when migrating from other distributions, there can be no other way to rescue data from an old system (e.g. Signal app on Ubuntu is a snap)

[jotapesse]

Skype is another example of being currently available (updated) only as a SNAP package. References:

1. skypeforlinux 8.110.76.107 says there is new versions available;
2. Skype for Linux Updates;

[Sepero]

From the link above:

Hello, Skype users!

We have some important news to share with you today. As you may know, Skype is available on various platforms, including Windows, Mac, Linux, Android, iOS, and web. However, maintaining different versions of Skype for different operating systems can be challenging and time-consuming. That's why we have decided to discontinue the distribution of Skype as DEB and RPM packages for Linux users, and instead focus on delivering Skype as a SNAP package.

[jotapesse]

Yes, that's why I mentioned it is "currently available (updated) only as a SNAP package". The previous DEB and RPM packages on which the NixOS skypeforlinux package is built are no longer maintained/updated. I tried it and it works with @io12's nix-snap. Thank you for that! But not that good unfortunately, menus/options get stuck and lag greatly. Not sure if it is due to nix-snap implementation or the skype snap package itself. The web version of Skype works much better by the way.