31–40 of 107 posts
An unfortunate name, a la Nonce Finance and Git. https://en.m.wiktionary.org/wiki/spack
Original author here -- since I know that people click the comments to decide whether to read further, here's a (biased?) summary: Spack is aimed at end users, developers, and admins. It's used primarily in HPC at the moment but it would be great to see use outside of the HPC community. Spack supports: 1. Basic installation (spack install foo, foo@3.1.2, foo@3.1.2 +option, etc.) 2. Reproducible environments, via `spa…
What do you think about Spack vs. Conda/Mamba? I've been a contented (maybe not "happy") Conda user for years. Is there any reason to switch? I'd be concerned about package availability.
* https://spack.readthedocs.io/en/latest/replace_conda_homebre...
The thing you'll likely notice most about Spack vs. conda/mamba/rattler(?) is that it lets you pick your versions and options much more fluidly, and it'll build you a package from source if there's no binary for it. Spack is much more seamless for integrating binary installations with source builds. `conda-build` is a whole other tool outside the normal user workflow.
Spack has over 7,000 packages at this point, so I don't think the lack of packages is going to hurt too much. We don't offer nearly as many public binaries yet, though, so the source builds may make the UX more painful, depending on what you're trying to do.
Original author here -- since I know that people click the comments to decide whether to read further, here's a (biased?) summary: Spack is aimed at end users, developers, and admins. It's used primarily in HPC at the moment but it would be great to see use outside of the HPC community. Spack supports: 1. Basic installation (spack install foo, foo@3.1.2, foo@3.1.2 +option, etc.) 2. Reproducible environments, via `spa…
Original author here -- since I know that people click the comments to decide whether to read further, here's a (biased?) summary: Spack is aimed at end users, developers, and admins. It's used primarily in HPC at the moment but it would be great to see use outside of the HPC community. Spack supports: 1. Basic installation (spack install foo, foo@3.1.2, foo@3.1.2 +option, etc.) 2. Reproducible environments, via `spa…
Very neat:) Given the similarity in features, could you comment on how it compares to nix?
From what I saw the package definitions are in python. Given python is really an imperative language I don't see how spack could be comparably powerful for definitions and reuse.
Original author here -- since I know that people click the comments to decide whether to read further, here's a (biased?) summary: Spack is aimed at end users, developers, and admins. It's used primarily in HPC at the moment but it would be great to see use outside of the HPC community. Spack supports: 1. Basic installation (spack install foo, foo@3.1.2, foo@3.1.2 +option, etc.) 2. Reproducible environments, via `spa…
Very neat:) Given the similarity in features, could you comment on how it compares to nix?
* Spack has a dependency solver (concretizer). nixpkgs is managed by humans who do the dependency solving for you over time. What this means practically is that you can install 5 versions of some package with different dependencies and flag combinations with a few commands in Spack, while with Nix you would probably need to check out different commits of the nixpkgs repo and maybe do some hacking on nix derivations to get the same thing. Spack is fundamentally designed to help with combinatorics.
* Nix builds all the way down to libc; Spack (currently) doesn't -- it's designed to live on an existing system.
* Nix build environments are isolated (but require root to run); Spack's aren't as completely isolated and don't require root (so you can run Spack in your home directory.
* Spack installation hashes are what Nix would call full configuration hashes -- they're configuration metadata hashes, not content hashes of the installation. So you could say we're not quite as committed to exact binary reproducibility, but you could also say that this allows us to support relocatable binaries (which Nix does not). Also, our metadata is pretty detailed.
* Spack's DSL is Python; Nix is, well, Nix.
Spack is very much inspired by Nix, and we talked about this a bit in the original paper here:
An unfortunate name, a la Nonce Finance and Git. https://en.m.wiktionary.org/wiki/spack
Earlier quoted context omitted.
Very neat:) Given the similarity in features, could you comment on how it compares to nix?
+100 From what I saw the package definitions are in python. Given python is really an imperative language I don't see how spack could be comparably powerful for definitions and reuse.
With Spack it's easier to contribute, you don't have to learn a new language as you need for Nix / Guix.
[1] https://github.com/spack/spack/blob/develop/var/spack/repos/...
Earlier quoted context omitted.
Very neat:) Given the similarity in features, could you comment on how it compares to nix?
+100 From what I saw the package definitions are in python. Given python is really an imperative language I don't see how spack could be comparably powerful for definitions and reuse.
Earlier quoted context omitted.
Very neat:) Given the similarity in features, could you comment on how it compares to nix?
+100 From what I saw the package definitions are in python. Given python is really an imperative language I don't see how spack could be comparably powerful for definitions and reuse.
The imperative part of a Spack package is the build recipe, which AFAICT is not so different from bundling a bash script in a Nix derivation. Just like Nix, it's included in our configuration hash, so if you change the recipe you get a different installation of the software.