1. 11
  1.  

  2. 2

    Would be interesting to do this with Nix, and add it to https://github.com/NixOS/bundlers

    1. 5

      That’s exactly what I wanted to do. I think it’s possible. There are two ways to achieve this:

      • reusing the runtimes provided by flathub, therefore having a small bundle size. With this solution we can’t reuse the packages already defined by nixpkgs.
      • bundling /nix/store inside the flatpak app. This means we can reuse the packages inside of nixpkgs, but then the bundle size will be huge.

      I’m still looking if there’s a viable and useful middleground.

      1. 1

        No. 2 sounds like the way Docker images are built in Nix nowadays, and they can be pretty small. Why would the bundle size inevitably be huge?

        1. 4

          Because flatpaks are designed to share runtimes. Most of gnome applications are importing and sharing the runtime org.gnome.Platform/x86_64/43. Each gnome app, if you have everything updated, is using a single gtk version from that runtime.

          By using option number 2, treating flatpaks as docker containers and bundling /nix/store, we’re going to link against a really specific gtk version, which is not the same as the one inside org.gnome.Platform/x86_64/43. The result will be an app which requires downloading that specific GTK version.

          Docker images generated with nix are small, because nix is smart enough to bundle exactly the minimum amount of dependencies. On the desktop though, you probably have 15 apps sharing GTK, so having 15 different docker images, even though they are small, with GTK copied each time is not great.

          The problem becomes bigger if we bundle python inside each app. In general, personal computer users care more about app sizes than developers care about docker image sizes.