4 ms·

Modern functional package managers like Guix and Nix do not use SAT solvers because they understand that package variants can differ by a lot more than just the

Modern functional package managers like Guix and Nix do not use SAT solvers because they understand that package variants can differ by a lot more than just their version number. The package graph is explicit in those systems and there are no constraints to solve for.

di4na 3y ago
Which is a complex way to say that humans do it by hand.
- chriswarbo 3y ago
  Sometimes; but there are also a bunch of "foo2nix" tools which can generate "packages" (individually, or sets of inter-dependent definitions) from other formats[0]. It's basically just generating (parameterised/overridable) "lock files". That's how Nixpkgs can contains massive collections like haskellPackages, pythonPackages, nodePackages, etc. (plus all the various copies with different compilers/interpreters/flags/etc., thanks to the overriding). It can still require some manual tweaking[1], but CI makes that easier, e.g. translate a few thousand definitions; send to CI; mark all those which fail to build as broken. [0] Actually, they generate functions which return derivations; Nix doesn't have a concept of "package", although the term gets thrown around informally. [1] Since those other formats are woefully inadequate at representing dependencies; not just the required compilers/interpreters themselves, but especially stuff like third-party C libraries, binaries that are assumed to be in $PATH, etc. PS: Those "foo2nix" tools don't need to be manually invoked; they can just be another derivation, whose result gets imported (via the import-from-derivation feature). That's how I tend to manage JVM projects (using mvn2nix).
- rcxdude 3y ago
  yes, but they also don't have the constraint that there can only be one version of a given dependency installed. So once you solve the dependencies for one package you have a solution for any combination of packages, unlike with traditional linux package managers.
- davexunit 3y ago
  I get the sense that you think this approach is inferior, but package managers based on version constraint solvers can't begin to approach the level of automation and reproducibility that exists in functional package managers. Lots of interesting stuff is not done by hand but through transformation with functions.

di4na 3y ago

Which is a complex way to say that humans do it by hand.

chriswarbo 3y ago
Sometimes; but there are also a bunch of "foo2nix" tools which can generate "packages" (individually, or sets of inter-dependent definitions) from other formats[0]. It's basically just generating (parameterised/overridable) "lock files". That's how Nixpkgs can contains massive collections like haskellPackages, pythonPackages, nodePackages, etc. (plus all the various copies with different compilers/interpreters/flags/etc., thanks to the overriding). It can still require some manual tweaking[1], but CI makes that easier, e.g. translate a few thousand definitions; send to CI; mark all those which fail to build as broken. [0] Actually, they generate functions which return derivations; Nix doesn't have a concept of "package", although the term gets thrown around informally. [1] Since those other formats are woefully inadequate at representing dependencies; not just the required compilers/interpreters themselves, but especially stuff like third-party C libraries, binaries that are assumed to be in $PATH, etc. PS: Those "foo2nix" tools don't need to be manually invoked; they can just be another derivation, whose result gets imported (via the import-from-derivation feature). That's how I tend to manage JVM projects (using mvn2nix).
rcxdude 3y ago
yes, but they also don't have the constraint that there can only be one version of a given dependency installed. So once you solve the dependencies for one package you have a solution for any combination of packages, unlike with traditional linux package managers.
davexunit 3y ago
I get the sense that you think this approach is inferior, but package managers based on version constraint solvers can't begin to approach the level of automation and reproducibility that exists in functional package managers. Lots of interesting stuff is not done by hand but through transformation with functions.