i use arch (btw), and i hate how much i depend on the AUR, its very unstable. I switched to flatpak for my gui programs since the cli experience sucks. nix on the other hand works like a native package manager, and thats great for me. but i see that nix also includes stuff like coreutils (because of nixos im guessing). do i install everything with nix? if not what packages do i install with pacman and which with nix?

  • hallettj@beehaw.org
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    I think use Nix for as little or as much as you want. I’ve been using Nix for a long time to get the odd package that isn’t available, or that isn’t completely up-to-date in the Debian repo. Now that I’ve learned more about it I’m using it for dev environments and packaging for my software projects, and I’m setting up NixOS and Home Manager on a new laptop.

    The low-level packages are there in case you need them. If you install anything that needs coreutils, libc, gtk, whatever Nix will install it automatically. It’s all fully isolated from the libraries that Arch installs so there is no need to worry about conflicts. But since Nix packages use only Nix dependencies you can run into some oddities when Nix uses different library versions than the host OS. For example I’ve had a case where a GTK app didn’t match the theme of the rest of my system.

    • naeap
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      when you say fully isolated from the Arch libs on the system, means I have all dependencies of the installed programs doubled on my system - only if needed of course. so they can’t share the same liberates already provided by the Arch/base system?

    • Atemu
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      If you install anything that needs coreutils, libc, gtk, whatever Nix will install it automatically

      That’s not quite right. They will be installed (chances are you have coreutils installed right now) but only as in “it’s in the Nix store”; they won’t automatically appear in your PATH or other shared state directories. You’d have to explicitly install the coreutils package for that to happen. I do that on my mac for example because I want GNU coreutils rather than macOS’ ancient modified BSD ones but, again, that’s an explicit choice.

      Some binaries may internally be wrapped to directly use Nixpkgs’ coreutils rather than the system ones. One example I can think of is git-annex which checks for coreutils features at build time. Giving it different coreutils at runtime could cause trouble, so it always uses Nixpkgs coreutils via a wrapper.
      That doesn’t mean Nixpkgs’ coreutils are “installed” into your system though, it’s just prepended to git-annex’ PATH. That’s the beauty of Nix.

  • priapus@sh.itjust.works
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I use Nix for CLI programs on most distros I use. In my configuration I have all the programs I want on distros other than NixOS in home-manager so that I can use it on any system and have my personal shell setup.

  • Atemu
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    I’d say anything that concerns the system (services, DEs, drivers, the kernel etc.) should be installed via the system package manager.

    User apps and dev envs can be installed from anywhere else, including FlatPak, Nix or language package managers such as pip.

  • chkno
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Whatever you want? / It probably doesn’t matter. / If it’s not causing pain why mess with it?

    When using nix on non-nixOS, it may be tricky to get the OS to use the nix-managed packages for core system / early boot stuff like linux (the kernel), systemd, agetty, xdm, etc., but usually there’s no need to. Nix packages bring all their needed dependencies, so even if nixpkgs is using a newer libc or something that’s not compatible with the system libc, things will still mostly* Just Work because the nix-built packages know exactly where to look for the nix-managed libc they were built with.

    (* Notable exception: OpenGL drivers, which for reasons are selected at runtime rather than build-time. See issue 31189 for some history.)