前几天，与技术好友做了一个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可以支持管理哪些包？