浅析spack较受关注的场景

前几天，与技术好友做了一个spack的分享会。收集到了一些比较关注的场景：

spack建议安装在本地还是NFS？

按照自己的公司规模与管理规范来。如是小公司，机器数量不多，计算服务器有本地硬盘，可以用spack将包安装到本地，访问速度更快。反之如果是大公司，拥有性能好的NFS，机器数量多，则将其安装到NFS。

对比于传统的包管理器如yum、apt、pip、conda等，spack它有什么优势？

前者做出的一些相当常见（但值得怀疑）的假设：

• 每个平台上，源码与二进制文件是1:1的关系。有利于重现，不利于性能优化。
• 二进制文件尽可能可移植。大多数发行版是这样做的，同样不利于性能优化。
• 工具链在整个生态系统是相同的。一个编译器、一组运行时库，解释性语言的话没有编译器。

而高性能计算与上述假设相违背：

• 代码通常以源码分发。供应商的库、编译器除外。
• 同一个包，经常会以不同的选项进行构建：开发者间的构建存在很大差异，当机器是新的时候，需要做首次的大量构建。
• 代码被优化适配于处理器与GPU：这可以高效地利用硬件，最高可以带来10-100x的性能提升。
• 很依赖于系统包：需要使用随机器的优化过的库，需要使用主机GPU库与网络。
• 多语言：C, C++, Fortran, Python等，全部都在同一个生态里。

spack可以管理多平台、多版本共存、多种编译选项的同版本包共存。

spack可以管理这么多包，但这些包不在spack服务器里面，那它的依赖是如何解决的？

spack管理的每一个包，都在各自的package.py文件里面，定义好了该包获取的路径与校验码，以及依赖包。但此处定义的依赖包关系则不会指定路径。依赖包的路径，又由对应的依赖包的package.py文件里面定义其获取包的路径。由此递归。

spack可以支持管理哪些包？