As described in the manual, Spack works best (espcially on older machiens) if you use a number of Spack-built packages in the environment used to run Spack. This creates a somewhat tedious bootstrapping procdure, in which the Spack admin has to check around the system for what is out of date, and then use Spack to install newer versions of those things. And you have to do it in the right order too (for example, some Spack packages won't download if you have SSL problems).
Now we have Spack depending on a YAML parser as well (for best performance).
Maybe it's time to build an auto-bootstrap procedure. When you give Spack the 'spack auto-bootstrap` command, it would root around your system, figure out what needs to be built, build it, and then include those packages in the Spack path forever after (even if you never put them in your .bashrc).
I think this could make it MUCH easier to install Spack on a wide variety of systems. Thoughts?
As described in the manual, Spack works best (espcially on older machiens) if you use a number of Spack-built packages in the environment used to run Spack. This creates a somewhat tedious bootstrapping procdure, in which the Spack admin has to check around the system for what is out of date, and then use Spack to install newer versions of those things. And you have to do it in the right order too (for example, some Spack packages won't download if you have SSL problems).
Now we have Spack depending on a YAML parser as well (for best performance).
Maybe it's time to build an auto-bootstrap procedure. When you give Spack the 'spack auto-bootstrap` command, it would root around your system, figure out what needs to be built, build it, and then include those packages in the Spack path forever after (even if you never put them in your .bashrc).
I think this could make it MUCH easier to install Spack on a wide variety of systems. Thoughts?