4 ms·

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 t

• 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
      I think that sums it up nicely. To add to that: Spack's solver effectively generates these 'concrete' packages for you. In the example, suppose you're packaging `X`, it depends on already existing packages `A` and `B`, and `A` needs `curl +foo` and `B` needs `curl +bar`; then Spack is convenient as you don't have to worry about the transitive dependency curl, the solver will output `curl +foo +bar`. That should make contributing to Spack potentially easier, cause you just have to define X, the solver will figure out the flavor of transitive dependencies, and there's no need to create the `curl-with-foo-and-bar` package (and you don't have to modify `A` and `B` to use `curl-with-foo-and-bar` either)