5 ms·

I'd guess that there is an insignificant minority of people who strongly prefer nix over anything else. And it might be because it is easy to provide and maint

by aerzen 21d ago

I'd guess that there is an insignificant minority of people who strongly prefer nix over anything else. And it might be because it is easy to provide and maintain compared to a .deb package.

mikepurvis 21d ago
Maintaining and providing a deb is pretty easy too; the real killer for a nix flake I think it's how dirt simple it is to provide infinite testing builds for different branches.
- aerzen 20d ago
  Well, for .deb there is the dependency problem. Even if your deb is just a release of a project, you can only use versions of dependencies that are in debian repository. Or include it all in your .deb, which becomes hard to maintain. By "infinite branches" you probably mean that a nix derivation / flake is a recipe that can build any version of the project?
  - mikepurvis 20d ago
    Yeah, Nix flakes can be a static URL path, but they inherit your VCS refs directly, so nix run github:tailscale/tailcat Gets you the default branch. Tailcat doesn't yet have any tags, but if you want a build of the main tailscale repo at a particular tag, it's just: nix build github:tailscale/tailscale/v1.102.3 But because this can be any ref, you can specify an arbitrary branch or tag, so like if you're trying to get a colleague to check out your work it's as easy as: nix run github:tailscale/tailcat/my-fancy-branch And obviously a flake can reference other flakes with the same flexibility, so your home manager config or your company's private app flakes can transparently pull the not-yet-merged version of a change you're proposing upstream without having to make special internal "patched" releases with tortured 1.2.3~actually.1.4.6 type version numbers like in Debian. And of course that same flake reference policy applies all the way down, so you also don't need to worry about the private apt repo as a big piece of shared state that's going rev forward and break your older code branches or Dockerfiles, since each branch of your app flake has its own flake.nix and accompanying lockfile controlling which deps it is pinned to. It really is an awfully nice system, and shockingly modern in its sensibilities considering how old the Nix fundamentals are.

by aerzen 21d ago

I'd guess that there is an insignificant minority of people who strongly prefer nix over anything else. And it might be because it is easy to provide and maintain compared to a .deb package.

mikepurvis 21d ago

Maintaining and providing a deb is pretty easy too; the real killer for a nix flake I think it's how dirt simple it is to provide infinite testing builds for different branches.

aerzen 20d ago
Well, for .deb there is the dependency problem. Even if your deb is just a release of a project, you can only use versions of dependencies that are in debian repository. Or include it all in your .deb, which becomes hard to maintain. By "infinite branches" you probably mean that a nix derivation / flake is a recipe that can build any version of the project?
- mikepurvis 20d ago
  Yeah, Nix flakes can be a static URL path, but they inherit your VCS refs directly, so nix run github:tailscale/tailcat Gets you the default branch. Tailcat doesn't yet have any tags, but if you want a build of the main tailscale repo at a particular tag, it's just: nix build github:tailscale/tailscale/v1.102.3 But because this can be any ref, you can specify an arbitrary branch or tag, so like if you're trying to get a colleague to check out your work it's as easy as: nix run github:tailscale/tailcat/my-fancy-branch And obviously a flake can reference other flakes with the same flexibility, so your home manager config or your company's private app flakes can transparently pull the not-yet-merged version of a change you're proposing upstream without having to make special internal "patched" releases with tortured 1.2.3~actually.1.4.6 type version numbers like in Debian. And of course that same flake reference policy applies all the way down, so you also don't need to worry about the private apt repo as a big piece of shared state that's going rev forward and break your older code branches or Dockerfiles, since each branch of your app flake has its own flake.nix and accompanying lockfile controlling which deps it is pinned to. It really is an awfully nice system, and shockingly modern in its sensibilities considering how old the Nix fundamentals are.