Desktop App Package Manager for Nix-based Distro

Edit: Should have made this clearer. In looking for a package manager to use on my distro. Not for a way to package my nix expressions for other distros.

I’m building my own distro based on NixOS and I’ve run into the problem of mainstream app packaging. I need to pick a package manager suitable for desktop use (graphical apps). It would be ideal to have a sandbox system and compatibility for apps built for more popular distros (like Debian/Ubuntu/Fedora). I’ll be using nix for configuration management and installation of command line apps, systemd services, etcetera. Here are my options:

  1. Flatpak - the one I’m considering the most at the moment. I’ve heard some discontent about it
  2. Snap - I don’t know much about it
  3. AppImage - I think people don’t like this one too much. I don’t know much about it either
  4. Build a custom solution with nixos-container, buildFHSEnv, and maybe dpkg (for compatibility with Debian and Ubuntu apps. I could use udev or the like to control which apps have access to what hardware and have custom daemons controlling which folders apps can see and access. If I’m careful I should be able to run a 100% stock app in the container environment and not have any problems yet retain my permissions system (for example, webcam is blank until user allows app to use it). Packaging should be simple since I’ll be using an FHS environment if necessary. I’m thinking something along the lines of a json or INI detention with a derivation/Deb file/tar archive/whatever, package name and version, and a list of dependencies to install into the environment

What pros/cons do you see with each and which do you think I should go with?

Thank you!

I have effectively used AppImage via nix-bundle. Then I package that up into a deb for things like service and udev files. Acts like a fat binary, installs with dpkg. Easy.

I think you misunderstood my question. I’m making a distro and trying to decide on a package manager to use for every-day desktop apps (Nix will be used for things like command line apps, libraries, system services, etc). I’m not looking to package a nix app for other distros

I would recommend Snap just because it has the most organizational support. You are most likely to find nonfree apps packaged using Snap, but not Flatpak. Otherwise it seems to me that Flatpak and Snap are almost identical.

AppImage and other solutions seems useful on systems without Nix installed, but otherwise, why not just use a Nix derivation? For free software, we should be able to build it in Nix expressions leaving closed source software the main obstacle above.

Could you elaborate what you mean by “organizational support”? Nonfree software isn’t a priority for me on this.

As for packaging everything in Nix, that’s a difficult and slow process. If I want X app available on my distro, I need to package it and its dependencies, submit a PR, wait until all of the packages in nixos-unstable work correctly (otherwise the channel won’t update) and then the app will be available in unstable. I assume getting it to stable is another waiting game. As much as I love Nix, Nixpkgs seems rather cumbersome. Moreover, there isn’t a sandbox technology behind it, though I guess one can be cobbled together.

It seems to me that Flatpak is edging out Snap right now. Fedora, Red Hat, Endless, and pretty much all of GNOME are supporting Flatpak. Snap is pretty much just Ubuntu and derivatives. Therefore, there will be more software choices with Flatpak. Am I wrong in this assumption?

If a package is missing in nixpkgs you don’t really need to wait and can package it yourself and just keep an overlay out of tree until it lands in stable.

As for Snap versus Flatpak, searching for % (as in SQL LIKE) on Snap search results for '%' — Linux software in the Snap Store and jumping to the last page it seems there are currently 2578 packages available while for Flatpak there are currently 407 (Flathub—An app store and build service for Linux). So I guess if you don’t want to use Nix packages, you might better off with Snaps.

PS: I’ve written a sandbox for Nix, which I intend to upstream soon, however it needs a bit of polish before it’s ready for submission.

As for overlays, I don’t want my user to be forced to compile every program they use. I don’t have the resources to host a binary cache. Maybe cachix may suffice, but for how long will it remain free/available? I doubt Cachix will support a distro-full of people using my apps. Moreover, I don’t have the resources to actually make the derivations - a lot of time (such as GNOME apps particularly, which my distro depends on) there are issues that require large changes in seemingly unrelated places (GNOME Builder took months to add in, and required work on many of the packages already in nixpkgs like python to get it to run). Then I’ll be obligated to maintain them, which I cannot do. I’m building this system alone. A DE and custom state management (stay tuned you’ll hear more from me about this) are enough work to do alone.

As for the amount of apps on Snap vs Flatpak, I’ve seen arguments about the types of apps there. Searching for “hello” yeilds about 250 hello world apps, and there are many such apps in snapcraft. Frankly, I also wouldn’t want to force my users to use Ubuntu One, which snap has done to me in all of my experience with it. Do they still enforce that annoying policy? If so, Snap is 100% a no-go for me.

Your nix sandbox looks interesting. I’ll keep an eye out. It still has the same packaging issues as regular nix, though.

From Cachix - Nix binary cache hosting

Will Cachix forever be free?

Yes. In the future there might be some limits, but at this point there are none.

Maybe @domenkozar can provide more info here.

Other than that, the moment your distro gets bigger the more options might be available to host a binary cache. Another option that was discussed a while ago and (probably) is still ongoing is integrating IPFS support into Nix:

If the package is generally useful and you bring it upstream, other people might use and maintain it as well, who knows?

It seems to still be the case.