91–100 of 107 posts
Earlier quoted context omitted.
I'm UK native and had never heard of the word as an insult. I wonder if it's a regional thing?
Well the UK has done an amazing job at getting rid of almost all uses of the word "spastic" due to the campaign against it, so it could be for that reason
Earlier quoted context omitted.
Well the UK has done an amazing job at getting rid of almost all uses of the word "spastic" due to the campaign against it, so it could be for that reason
I'm old enough to remember that and some other derivations being very common in the playground. Just not this one.
Earlier quoted context omitted.
Very neat:) Given the similarity in features, could you comment on how it compares to nix?
Main differences with 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 h…
One nice feature of Nix is the "import from derivation" pattern: if some Nix definition happens to call the built-in functions 'import' or 'readFile' with a path to some other Nix derivation (AKA build product), Nix will first build that derivation, then import the resulting file to finish evaluating the original definition.
This way, we can have one derivation which runs some arbitrary dependency-solving command; and import its result as part of our package's definition. We do this where I work: we run the `mvn2nix` command inside one derivation, to get a JSON file describing our Maven project dependencies (jar and pom files); this is imported, and used to define a self-contained folder of those jar and pom files; then the main project definition runs Maven pointing at that folder.
The downside of this approach is that it slows down evaluation: Nix usually has an "evaluation phase", where we figure out what to build; then a "build phase", which runs those builders. When we "import from derivation", this distinction is lost: in order to figure out what to build (e.g. which Maven command to run, to build our project), we must first do some building (e.g. to figure out what should go in the folder that Maven will look in for dependencies). For this reason, the Nixpkgs repo doesn't allow definitions which use "import from derivation"; however, it's a very handy tool for our own personal or organisational projects :)
(PS: Many years ago I tried to do something similar for building Haskell projects; but never really got it to work :( )
I'm surprised that no one here has talked about the build times yet. As a new user, the first thing you notice out of the box is that even on a relatively beefy system, you spend ~2 hours getting to a working state, even when you're building a relatively modest set of packages. This is particularly surprising since one of the points of Spack is to integrate with the existing system software, and so much of what you'r…
Try spack external find, and much of this problem goes away. It will register the existing packages as externals.
As to the rest, spack actually has public binary mirrors with builds of many packages for common distributions now, in addition to the E4S mirror. It may not be as easy to ensure use of these as would be ideal, but this situation has gotten much, much better over the last few years.
An unfortunate name, a la Nonce Finance and Git. https://en.m.wiktionary.org/wiki/spack
Interesting, the same word with the same insulting meaning is used in northern Germany…TIL it‘s in English too. Maybe a leftover of the british occupation after WWII. Spacken Spacko Spack
I’ve tried to like this more than once, but once you hit some cryptic error somewhere in the build you’re not going to have a great time. Also unfortunately it doesn’t always play nicely with lots of high energy physics software which really leans on using LD_LIBRARY_PATH and running custom executables during builds. I’ve had bad experiences with ROOT and Gaudi with no obvious paths forward for fixing things.
For instance, several times I've had Spack in a state where it had obscure apparently internal errors that I didn't have the energy to try to diagnose, which resulted in throwing everything away and starting again. I found build recipes frequently don't actually work, especially if you're not on x86_64, though architecture accounts for a minority of the failures. You also end up quickly running out of space in ~10GB of home directory, at least if things aren't shared on the system.
There is a tension between "reproducible" static configurations and the dynamics you need, e.g. to be able to link instrumentation or acceleration libraries at run time. However, there is a Spack option to use RUNPATH instead of RPATH that I'd have to look up.
I’m naive about HPC, but it’s always surprised me a bit that HPC software seems to be a fairly distinct ecosystem. I’m not doubting it’s for good reasons, but why is a special package manager needed for this domain?
I’m naive about HPC, but it’s always surprised me a bit that HPC software seems to be a fairly distinct ecosystem. I’m not doubting it’s for good reasons, but why is a special package manager needed for this domain?
HPC isn't exactly special, and neither to some extent is Spack. Spack's gotten some attention in talks at, e.g., CppCon. The big differentiator is really the degree to which people want to tune and customize their builds in HPC vs. other communities, and the diversity of hardware that needs to be supported. Things that stand out to me: - different applications' needs to customize the builds of their dependencies - e.…
Nix is great for full system management. Less so for something like python package management. Its lack of a dependency resolver or multiple versions of a package within the same nixpkgs instance makes it difficult to work with in some (lots of) instances. Generally, I use pipenv or poetry from within a nix flake to define the environment.
Spack doesn't seem to cover system management (please correct me if I'm wrong here, but it seems to be out of scope). Combining them: using spack within a flake to define and build a set of dependencies seems like the best of both worlds.
Unfortunately, at the moment, it doesn't appear to be available in nixpkgs.