Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).

NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.

I don’t get why more people aren’t using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I’m also scared that there is a downside to them I dont know about.

  • Atemu@lemmy.ml
    1·
    9 months ago

    It tends to get your software out there and used faster if you bootstrap the packaging

    It’s fine to provide some sort of “official” binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.

    My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.

    it’s easy on most distros

    It all depends on what you’re used to and how cursed the project’s build process is.
    For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn’t want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.

    On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.

    It’s the same for NixOS. When I encounter something that somehow isn’t packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
    There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.