3 ms·

> yet if I understand correctly, it often has one version per package per Nix version? Both yeah and no. Taking the example of nodejs, you have all the support

• stabbles 3y ago
  The main difference is that Spack has a single definition of a package, and in Spack language `curlMinimal`, `curlWithGnuTls`, and `curlHTTP3` are all "concretizations" of curl. That has the advantage that dependents can say `depends_on("curl")` if they don't care about the flavor -- only if they somehow require curl with GNU tls, they say `depends_on("curl tls=gnutls")`.
  • nathan_phoenix 3y ago
    Oh, didn't know, thanks for the explanation! Does seem like an interesting concept, will check out Speck more in-depth.
  • aseipp 3y ago
    Nix also has a single definition of the curl package. The curl package itself can take tons of flags as inputs, indicating how it should be built, and you can then have curlMinimal, curlWithGnuTLS, and curlHTTP3 all as different 'names' for curl with those arguments applied. A package just says it has a 'curl' input and any user can "call" that package, providing any flavor of 'curl' they want as input. You can override those inputs at a global level and local level in various ways. I suspect you mean some other semantic difference, but if that's all you mean, it's not different from Nix in practice, from what it sounds like? https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/networking/curl/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/netw...
    • stabbles 3y ago
      Maybe I'm misunderstanding, but my impression is that Spack is more composable: In Spack pkg A can say `depends_on("curl tls=gnutls")`, pkg B can say `depends_on("curl +nghttp2")`, and if you then request a package that depends on both A and B, you end up with `curl tls=gnutls +nghttp2` as a transitive dependency. It sounds like in Nix it's either/or: if you need both curlWithGnuTLS and curlWithHTTP2, what do you do?
      • rgoulter 3y ago
        My background is the Nix side of things. I'm getting the impression that the main difference here is that Nix's approach is more 'concrete'. In Nix-world, you'd describe your package as a function, where the inputs are parameters. Something like `function myPackage (curl, gcc) { ... }`. When this `myPackage` is built, you can pass in what you want `curl` to be. So, you'd think that it's something like `curlWithGnuTLS = curl(..., GnuTLS = true)`, and then could have something like `myPackageWithCustomCurl = myPackage(curl = curlWithGnuTLS, ...)`. To give more specific Nix examples, here's where `curlWithGnuTLS` is defined https://github.com/NixOS/nixpkgs/blob/dbf6c323883ae7e00941f628e65bdd58b3660e9a/pkgs/top-level/all-packages.nix#L6991 https://github.com/NixOS/nixpkgs/blob/dbf6c323883ae7e00941f6... By convention, the packages that want curlWithGnuTLS specifically use that name as an argument. (That's because `callPackage` will use the argument names to find the values to assign to it). In nix, customising these package arguments from the CLI isn't really ergonomic. It sounds like with Spack, there's more emphasis on being able to specify those parameters from the command line when installing things. That said, to the question about different dependencies: if package A depends on curl-with-foo, and package B depends on curl-with-bar.. it does depend on how it's declared, but Nix is comfortable to have package A linked against curl-with-foo and B linked against a separate curl-with-bar. -- Although it would also be possible to declare a curl-with-foo-and-bar and pass it to each. e.g. on my machine, if I run `ls /nix/store/ | rg 'curl.-.-bin'`, I have dozens of lines like: m2h1p50yvcq5j9b3hkrwqnmrr9pbkzpz-curl-7.86.0-bin mxaq2w1dzq5msgk2kc4vl1dfs54dv5ny-curl-8.0.1-bin nsz5w44p42xb39xninjkmj2dxzm13f7g-curl-7.79.1-bin
        • stabbles 3y ago