Todd Gamblin

Spack 创始人，劳伦斯利弗莫尔国家实验室（LLNL）计算机科学家

简介

Spack 已经存在一段时间了，通过 GitHub、Slack 和我们的 Google 小组等渠道，我们一直感觉对社区有很好的了解。然而，该项目规模正在扩大，我们希望通过更结构化的反馈来更好地了解社区需求。Spack 由 NNSA ASC 项目和美国百亿亿次计算项目 (ECP) 资助，我们希望了解 ASC、ECP 和其他类型用户在需求上的差异。

因此，今年我们进行了首次 Spack 用户调查。请继续阅读以查看结果。

关于调查

本次调查包含 26 个选择题和 6 个简答题。调查开放时间为 9 月 28 日至 10 月 9 日，共有 169 名受访者。我们通过所知的最广泛渠道进行了宣传。具体而言，我们通过以下渠道推广了调查：

  • 我们的 Google 小组（402 名成员）；
  • Slack（约 900 名成员）；
  • Twitter（约 1,100 名关注者）；
  • ECP 全局邮件列表（ECP 约 1,000 人）；以及
  • El Capitan 卓越中心 (COE) 邮件列表。

这些列表之间可能存在大量重叠，因此受众可能不像看起来那么广。由于邮件列表中的人员非常集中于美国，调查结果可能偏向于美国用户。因此，虽然样本绝非科学严谨，但我们至少知道它涵盖了许多 Spack 用户。

数据

结果在此总结，您可以在此处获取完整数据集以及我们用于生成这些图表的脚本。结果非常丰富——如果您发现了我们忽略的任何有趣内容，请告诉我们。

致谢！

感谢 169 名参与调查的用户，感谢你们的反馈以及对 Spack 的持续贡献！没有社区的支持，这个项目就不可能实现！

受众概况

在调查的这一部分，我们试图了解 Spack 社区的组成。

ECP 和 Spack

我们问的第一个问题是受访者是否属于 ECP。

ECP 占社区的比例略高于三分之一（约 35%，即 169 名受访者中的 61 名）。它包括来自美国能源部双方的人员——NNSA 实验室（如 LLNL、LANL 和 Sandia）以及科学办公室实验室（如 ANL、ORNL、LBL、PNNL、BNL 等）。在 ECP 下，Spack 团队专注于为美国首批百亿亿次计算机器提供软件栈，其中包括即将推出的系统，例如：

  • LBL 的 Perlmutter：AMD CPU / NVIDIA GPU（百亿亿次计算前沿系统）
  • ANL 的 Aurora：Intel CPU / Intel GPU
  • ORNL 的 Frontier：AMD CPU / AMD GPU
  • LLNL 的 El Capitan：AMD CPU / AMD GPU

所有这些都是 HPE/Cray 系统，但硬件非常多样化（尤其是 GPU）。我们想看看处于高性能计算 (HPC) 前沿的用户是否与整个 Spack 社区有着截然不同的需求。因此，在随后的各部分中，我们分别呈现了针对 Spack 全体和 ECP 用户的响应。

您的用户身份是什么？

我们询问了用户在组织中扮演的角色。

Spack 最初的目标受众是用户支持团队和系统管理员，但目前社区中绝大部分是终端用户（科学家/研究人员，占 35%）和软件开发人员（41%）。系统管理员约占整个社区的 11%，而用户支持人员仅占 8%。在 ECP 中，这一趋势更为明显——只有极少数受访者自认为是系统管理员，而开发人员占 ECP 用户群的近 43%。

系统管理员缺席的部分原因在于，在能源部实验室，管理员通常不负责用户软件的安装——这是留给与用户互动的专业支持团队。管理员（至少在能源部）倾向于专注于保持机器运行和管理 Spack 底层的宿主操作系统。

如果您将其与 EasyBuild 的最新调查（第 13 页）进行比较，您会发现社区组成截然不同。在 EasyBuild 的类似调查中，只有 3% 的受访者自认为是开发人员，只有 9% 是科学家。用户支持和管理员分别占 EasyBuild 用户群的 26% 和 53%。

您在哪里工作？

接下来我们询问了用户的工作地点。

社区整体是多元化的。略少于三分之一 (31%) 来自大学。37.6% 来自能源部 NNSA 和科学办公室实验室（超过了所有 ECP 的比例——因此包含了不属于 ECP 的能源部部门）。其他公共研究实验室占 Spack 用户的 18%，约 13% 来自私营公司和云服务提供商。在 ECP 内部，绝大多数用户 (76%) 来自能源部实验室，但也有一些来自公共实验室和大学的参与者。

再次与 EasyBuild 的调查（第 13 页）相比，我们可以看出 EasyBuild 的用户中来自国家计算中心的用户比例要小得多 (13% 对 37%)，而来自大学的用户比例更高 (55%)。很难准确比较比例，因为 EasyBuild 的调查提供了“大学研究小组”选项，而在我们的调查中，这可能分散在“大学 HPC 中心”和“公共研究实验室”类别中。

您在哪个国家/地区？

略少于三分之二的 Spack 用户在美国，如果加上两名加拿大受访者，几乎恰好三分之二来自北美。27% 来自欧洲，5% 来自亚洲，中东（沙特阿拉伯）和南美（阿根廷）各有一名受访者。在 ECP（这是一个美国能源部项目）内部，这一比例要高得多——近 97% 来自美国。

您的主要应用领域是什么？

这些结果与我们预期的基本一致——大多数 Spack 用户（约 80%）从事传统的高性能计算和模拟。在更广泛的社区中，约 30% 从事计算机科学研究，但在 ECP 内部，约 50% 从事计算机科学研究。在 ECP 中，人工智能和生物信息学的受关注度明显低于更广泛的 Spack 社区。有趣的是，编译器测试是 ECP 之外第 7 大最受欢迎的应用领域，但在 ECP 内部它是第 4 大最受欢迎的。只有一名用户报告将 Spack 用于 Web 应用程序。

您是如何了解 Spack 的？

无论是在 ECP 内部还是外部，约有一半的 Spack 用户通过口碑听说过该工具。这个结果让我们很高兴——我们认为这意味着用户非常愿意向朋友推荐 Spack。除了口碑，22% 的人因为在他们所在的站点使用了 Spack 而听说它。在 ECP 内部，这一比例稍高，为 30%。

24% 的用户通过外联活动了解 Spack：教程、BOF 会议和演示。

您使用 Spack 多久了？

Spack 的使用率随着时间的推移而增长，每年加入社区的用户数量也在增加。整个社区中大多数人使用 Spack 的时间不到两年。我们在 GitHub 上的项目贡献者数量中也看到了这种效果。2018 年，在该项目公开发布 4 年后，贡献者大约有 300 人。2 年后，已有近 700 人。

在 ECP 内部，社区更为成熟——大多数人是在 2-3 年前开始使用 Spack 的。此后的新采用率较低，我们将其归因于 Spack 在 ECP 中的快速普及。Spack 在那里很快流行起来，人们一直在使用它，并没有大量新用户涌入 ECP。人口结构随时间保持大致稳定。

您为 Spack 做出过贡献吗？

约 75% 的受访用户以某种方式为 Spack 做出了贡献，其中大多数（60%）贡献了一个软件包。近 40% 的用户在 Slack 上活跃，近 40% 在 GitHub 上提交了问题。

值得注意的是，Slack 上的讨论比 Spack 邮件列表要活跃得多——用户似乎更希望进行实时交流，而不是来回发送电子邮件。

没有多少用户（约 10%）为文档做出过贡献，但即使是这一小部分贡献也有助于项目——这大约是 16 人。

对于 ECP 而言，似乎没有什么特别的启示，只是 ECP 用户似乎更有可能贡献软件包（近 70% 的用户这样做过）。

Spack 使用情况

在对用户群进行定性后，我们继续探讨他们如何使用 Spack。

您使用哪些版本的 Spack？

Spack 用户喜欢处于最前沿，这体现在他们使用的 Spack 版本上。略少于 60% 的用户使用 Spack 的 develop 分支，在 ECP 中这一数字更高（约 65%）。下一个最受欢迎的版本是 0.15，这是本次调查时最新的 Spack 版本。

相对较少的用户使用旧版本，尽管有极少数人使用 0.10。从那时起发生了很大变化——0.10 发布于 2017 年 1 月，当时大约有 1,000 个软件包（现在为 5,000 个）。我们希望仍然使用 0.10 的用户能够升级——无论是为了功能还是为了软件包修复。

您在什么操作系统上使用 Spack？

Spack 用户的操作系统（左）以及特定的 Linux 发行版（右）。

Spack 的目标是 HPC，因此近 100% 的用户在 Linux 上使用它并不足为奇。用户有时忘记了 Spack 也可以在 macOS 上运行。约 35% 的所有用户在 Mac 上运行 Spack，ECP 内部超过一半的用户也在 macOS 上运行它。少数用户（<10%）在 Windows Linux 子系统 (WSL) 内运行 Spack。我们不在那里测试，但我们被告知 Spack 在 WSL 环境中运行良好。

如果我们更详细地查看响应，可以看到用户正在运行的具体 Linux 发行版。最受欢迎的是 CentOS 和 Red Hat。在 ECP 中，Red Hat 特别受欢迎。Ubuntu 是继这些之后最受欢迎的，其次是 macOS，然后是其他 Linux 发行版和 WSL。SuSE 在 ECP 内部比在更广泛的社区中更受欢迎，这很可能是因为它大多数 Cray 系统构建于该 Linux 发行版之上。

过去一年中，您使用 Spack 安装了多少次软件？

近 28% 的社区完成了超过 200 次软件安装，超过 12% 完成了超过 1,000 次安装。ECP 的数字与一般人群相似，但分布略微偏向于更多的安装量。

您使用什么版本的 Python 来运行 Spack？

Python 2 的支持于 2020 年 1 月 1 日结束，但近一年后，约 40% 的 Spack 用户仍在使用 Python 2.7。有 4 名用户甚至在使用 Python 2.6。Python 2.7 在许多操作系统上仍然是系统 Python 版本，包括 Red Hat 7 和 CentOS 7，而在 Red Hat 和 CentOS 6（一些站点仍在使用）上，默认值是 2.6。

虽然许多项目可以选择自己的 Python 版本，但 Spack 往往是人们用来安装更新版本 Python 的工具，我们不想让用户为了安装 Spack 的依赖项而去使用另一个安装程序。我们希望它能够开箱即用，因此我们努力使 Spack 在任何地方都能与系统 Python 一起工作。

如果 Spack 放弃对 Python 2.6 的支持，会有多大影响？

我们询问是否可以放弃对 Python 2.6 的支持，结果发现仍有约 4 个“顽固分子”确实需要 Spack 在 Python 2.6 上工作，而且超过 20% 的人会因为这一变化而感到至少轻微的不便。目前，我们将继续支持 Python 2.6，但您可能会预期在未来一年内宣布其弃用，随着最后几个 Red Hat 6 安装的减少。

如果 Spack 仅支持 Python 3，会有多大影响？

最终，我们希望完全放弃 Python 2，但由于 40% 的用户仍在使用 2.7，且 36% 的用户可能会因这种转变而感到困扰，我们将暂时推迟放弃对 2.7 的支持。有趣的是，虽然 ECP 用户不像更广泛的社区那样完全反对放弃 2.6，但他们比社区更反对放弃 2.7。

您如何将已安装的 Spack 软件包引入您的环境？

使用 Spack 软件包的最常见方式仍然是通过模块 (modules)，且模块的使用似乎在 Lmod 和 TCL 模块之间平分秋色，并存在一些重叠。令我们惊讶的是，spack load 命令是使用 Spack 软件包的第二大流行方式，仅落后模块几个百分点。

我们没有关于过去使用 spack load 的数据，但我们努力使其在任何地方都能轻松使用，这可能导致了其使用量的增加。特别是在早期的 Spack 版本中，spack load 要求模块才能工作（它是 module load 之上的一层薄薄的封装）。从 2020 年初的 Spack 0.14 开始，它只需要 Spack 自己的环境支持——因此您可以轻松地在 Mac 或个人 Linux 机器上加载一次性软件包，而无需预先安装模块。

在 spack load 之后，约 35% 的用户正在利用 Spack 环境将一组软件包组合在一起加载。像 spack load 一样，Spack 环境不需要模块系统的支持——它们可以在任何部署 Spack 的地方工作，并提供了一种比加载环境变量模块更具可移植性的替代方案。

您使用哪些 Spack 功能？

虽然 Spack 环境在简单地将软件包引入 PATH 方面排名低于模块，但环境实际上是 Spack 中使用最广泛的单一功能（至少在我们这里的列表中）。约三分之二的用户表示他们使用环境。环境可用于将软件包添加到 PATH，通过 spack.yaml 维护依赖项列表，在存储库中对 spack.yaml 环境进行版本控制，进行组合构建，使用 spack.lock 重现构建，配置和运行 CI 管道，以及构建容器映像。

展望未来

我们想了解用户在未来一年对 Spack 的需求，因此我们询问了关于即将推出的架构、Spack 功能和事件的情况。

您预计明年会在 Spack 中使用哪些 CPU？

几乎 Spack 社区中的每个人都计划在明年运行 Intel CPU，约 80% 的人预计将使用 Spack 为 AMD 系统构建。略高于 40% 的用户将在 ARM 上运行，略低于 40% 将在 Power 上运行。在 ECP 内部，希望在任何非 Intel CPU 上运行的用户比例更高——正如您所料，ECP 的目标是更多样化的架构集。有更多的 ECP 用户预计在 Power 上运行，这很可能是因为当前美国排名前两位的系统 Summit 和 Sierra 是 Power 机器。

在这个问题上，我们无法与 EasyBuild 进行公平的比较，因为 EasyBuild 的调查询问用户当前正在使用哪些 CPU，而不是预计明年使用哪些，而且他们的调查是一年前进行的，HPC 的变化很快。所以，请对这些数据持保留态度，但差异仍然值得一提。在 EasyBuild 调查（第 26 页）中，绝大多数用户同样在 Intel 机器上运行。但是，不到 20% 使用 AMD 芯片，不到 5% 使用 Power，只有一名用户报告使用 ARM。在下次调查中，他们针对 AMD 和 ARM 的数字很可能会增加。

您预计明年会在 Spack 中使用哪些 GPU？

Spack 社区中的所有用户都预计明年会在 GPU 上运行，超过 90% 的人计划为 NVIDIA GPU 进行构建。整个社区中约有一半预计为 AMD GPU 构建，约 30% 预计为 Intel GPU 构建。在 ECP 内部，计划在 NVIDIA GPU 上运行的用户比例略低，这很可能是因为 NVIDIA 不会是最初三台百亿亿次计算机器中任何一台的 GPU。Aurora 将是 Intel GPU 系统，Frontier 和 El Capitan 都将使用 AMD GPU。正如您所料，80% 的 ECP 用户预计使用 AMD GPU，超过一半预计使用 Intel GPU。

EasyBuild 社区中的 GPU 使用率同样很高——96.5% 的 EasyBuild 用户正在为 GPU 编译软件——因此 GPU 已在 HPC 中普及开来，这一点很明显。

您预计明年会在 Spack 中使用哪些编译器？

正如您根据 CPU 和 GPU 结果所预料的那样，Spack 用户预计将使用范围极其广泛的编译器。gcc 仍然是王者，近 100% 的用户预计会使用它，LLVM 和 Intel 编译器紧随其后。

有趣的是，只有约 60% 的人计划使用 nvcc，略多于 40% 的人计划使用 NVIDIA 的 HPC 编译器。考虑到超过 90% 的用户表示他们预计在 NVIDIA GPU 上进行构建，我们倾向于通过以下方式解释这种差异：很大一部分用户预计使用的不是通过 CUDA 直接使用 NVIDIA GPU，而是通过 GPU 优化库或 OpenMP 卸载等编译器功能。对于 AMD 和 Intel GPU 可能也是如此——计划使用专门针对这些 GPU 的编译器的用户比例始终低于预计使用它们的用户数量。

按重要性对即将推出的 Spack 功能进行排名

我们要求受访者按重要性对一些计划中和尚未计划的 Spack 功能进行排名：“不重要”、“稍微重要”、“比较重要”、“非常重要”和“关键”。两个最常被评为“关键”（并且按平均分计算排名前两位的功能）是重用外部安装和新的具体化器 (concretizer)。这些是相关的，因为需要新的具体化器来重用现有的安装。

在此之后，最重要的功能是更好的编译器标志处理和更好的开发人员支持。构建依赖项的单独具体化（即，即使用户要求主软件包使用 Intel 编译器构建，也使用 gcc 为 CMake 等软件包构建）排名紧随其后，接下来是语言虚拟化（能够依赖 cxx、c 或 fortran 并将其解析为编译器和运行时库）、GitHub 上的自动软件包维护者通知以及构建测试。

评分最低的功能是构建测试、公开可用的优化二进制软件包、软件包测试、Spack 云集成和 Windows 支持，后三项的评分明显低于其他所有功能。

每个功能都至少被一些用户列为“关键”，但这里有一些明显的偏好，我们将努力根据这些偏好调整我们的工作。我们已经在 Spack v0.16.0 中将新的具体化器作为实验性功能发布，并且已经在 Spack v0.16.1 中合并了许多修复程序。构建依赖项的单独具体化和重用现有安装都是我们需要对新具体化器进行的修改，我们已经开始研究如何提供它们。更好的开发人员支持、语言虚拟化、维护者通知、更好的构建测试和软件包测试已经是 2021 年的里程碑。

尚未纳入我们计划的突出功能是更好的编译器标志处理。根据这项调查，我们也将看看是否能将其纳入 2021 年的时间表。

按工作场所（左）和工作类型（右）划分的功能评分。

除了上述社区范围的平均值外，我们还查看了社区的不同细分群体是否对功能的评价不同。在右上方的图中，我们按工作场所拆分了平均功能评分，在左侧，我们按工作类型拆分了它们。

总体而言，不同工作场所和工作类型的排名顺序相似。重用现有安装和新的具体化器始终排在每个人的榜单之首，评分最低的功能在各处的评分都很低。行业用户将云集成排在明显高于其他群体的地位，而用户支持人员对软件包测试的评价远高于其他工作类型（也许是因为他们更多地参与了所在站点的软件包测试工作）。经理和 ASCR 实验室对单独构建依赖项的评价低于其他群体。除了这些异常值之外，与总体偏好顺序没有显著偏差。

跨群体确实存在一些值得注意的趋势。系统管理员、用户支持人员和行业用户倾向于在整体上将功能评为不那么重要。很难知道如何解释这一点——这可能意味着他们对 Spack 的现有功能感到满意，或者这些特定的改进不是他们的首要任务。

如果我们举办一场关于 Spack 的（虚拟）研讨会，您会参加吗？

我们考虑举办 Spack 用户会议已经有一段时间了，并且实际上在今年早些时候已经开始计划首届 Spack 用户会议。但随着疫情爆发，计划落空。其他类似工具在这样的会议上取得了不错的成绩（例如 NixCon 和 EasyBuild 用户会议），因此我们询问了用户对潜在虚拟会议的看法

略超过一半的用户（超过 85 人）表示他们会参加，17 人表示他们愿意进行演示。这对于初次 Spack 会议来说似乎绰绰有余，因此请期待我们在 2021 年宣布相关消息。

获取帮助

我们有兴趣让学习 Spack 变得更容易，因此我们询问了人们目前是如何学习的。

您参加过 Spack 教程吗？

令我们惊讶的是，我们超过 60% 的用户参加过 Spack 教程。自 2016 年以来，我们一直在 Supercomputing、ISC 和 PEARC 等会议上举办 Spack 教程，今年我们在 AWS 上的虚拟 Spack 教程有超过 125 名参与者。这似乎表明教程已成为一种非常有效的推广形式，尽管它们不是人们最初听说 Spack 的主要方式（根据我们之前的问题）。至少，它们可能有助于社区中的高贡献率。

当需要帮助时，您如何获得 Spack 的相关支持？

用户比其他任何地方都更常访问 文档以获取有关 Spack 的帮助。Slack，如上所述，也非常受欢迎——50% 的用户使用它来获得帮助。我们很高兴看到约 40% 的用户从同事那里获得帮助，当我们进一步查看这些数据时，从同事那里获得帮助的人并不局限于大型实验室——他们来自我们考虑的所有类型的工作场所。

您多久查阅一次 Spack 文档？

用户相当频繁地查阅文档——大多数人每周到每月查阅一次。一小部分人（14%）每天查阅。ECP 用户平均比整个社区更少查阅文档，但ECP 用户使用 Spack 的时间也更长，因此可能更熟悉它。

如果 Spack 提供商业支持，您或您的组织会购买吗？

我们目前没有任何计划为 Spack 提供商业支持，但知道 23%（即 39 名用户及其组织）可能愿意为此付费是件好事。这是愿意为开源产品付费支持的用户中相当大的比例。

Spack 质量

我们以最后一个问题结束了调查的选择题部分，要求用户评价 Spack 的质量。

您如何评价 Spack 的整体质量、社区、文档和软件包？

类似于我们上面关于功能的问题，我们要求用户将 Spack 的不同部分评为“糟糕”、“不好”、“尚可”、“好”和“优秀”。我们按工作场所和工作类型拆分了结果

按工作场所（左）和工作类型（右）划分的质量评分。

所有类别的平均响应都是积极的。只有 3.5% 的用户对 Spack 的整体质量给出了负面评价（相比之下，EasyBuild 为 2%，第 60 页）。只有 5% 的用户对任何方面给出了负面评价。一致地，评价最高的是社区，这非常棒，因为没有社区的支持，Spack 将无法持续存在。紧随社区之后的是 Spack 本身。

虽然社区和 Spack 的平均得分总体上都在“好”或更高，但文档和软件包的平均评分最低。虽然一些用户称赞了文档，但积累了大量的文档，很可能需要更好地整理。Spack 面向许多不同类型的用户，且不止一种工作流程。我们收到了许多请求，要求为常见的站点部署和开发人员工作流程提供更清晰的入门指南，这是我们计划在明年解决的问题。

Spack 软件包是一个更难解决的问题。软件包 DSL 是 Spack 独特性的一部分——每个软件包都有一个模板，同一个模板允许您构建软件包的任何版本或配置。这使得将 Spack 软件包移植到新系统更容易，但也使得 Spack 软件包的测试表面非常大。我们认为我们仍然走在正确的道路上，原因有几个

  • 我们与 Kitware 一起，利用 Spack 环境中内置的管道支持，建立了一个复杂的 CI 系统。
  • 我们已将我们的 GitLab 实例连接到 Spack 的主 GitHub 存储库，并且在接下来的几周内，我们将测试每个拉取请求上的 Spack 构建子集。
  • 这些是用于产生 ECP 的极限尺度科学软件栈 (E4S) 的相同构建。

我们在 2021 年 ECP 下的优先事项之一是强化这些构建并在各种平台上测试 Spack 软件包，现在新的具体化器已在 Spack 中，我们预计能够根据我们的管道和 E4S 下的构建，将 Spack 配置导向经过充分测试的配置。因此，我们预计软件包的稳定性在未来一年内会好得多，我们希望这会体现在明年的调查响应中。

简答题

我们提出了 6 个简答题。如果您愿意，可以在数据存储库中阅读全部内容。这些回复的数量和长度非常惊人，我们还没有想到一个很好的方法来总结它们，但阅读它们给了我们一个很好的图景，了解社区中的人们在做什么。我们为每个问题挑选了一些回复并引用在下面。

请简要介绍您的用例和通常的 Spack 工作流程。

  • 我正在使用 Spack 为我们大学的集中式 HPC 系统构建用户软件环境。

  • 使用 Spack 原生构建复杂的应用程序。如果可能的话，使用 spack containerize 将构建移入容器。

  • 我们使用 spack 为我们的核物理软件环境提供 3 个一致的入口点：cvmfs、build_caches、containers。

  • 相当异构的集群，每个架构一个环境。目前在打包生物信息学工具方面非常有乐趣。

  • 在富岳 (Fugaku) 中支持 Spack

  • 我是一名数学库开发人员，使用 spack 来构建第三方库，例如 blas、lapack、MPI、hypre、SuperLU_MT、SuperLU_DIST、PETSc 和 Trilinos，既用于在我的笔记本电脑上进行开发，也用于专用工作站上的持续集成。

  • 我们使用 spack 在 OLCF HPC 机器上安装大多数设施提供的软件。

  • 带有 Spack 环境的分布式构建系统

Spack 的哪些方面对您帮助最大？

  • 社区

  • Greg Becker 在 Slack 上回答了我的问题。

  • Spack 如何处理同一应用程序的多个版本安装。

  • Spack 如何做到 Linux OS 不可知论（尚未测试），以便我们可以尝试为用户提供其他发行版。

  • 绝对的灵活性，特别是与 nix 相比。还有依赖项处理，我再也不想手动执行了。

  • 我仍然处于依赖地狱中，但 Spack 让我从第七层（暴力——对于我在构建东西时想对键盘施加的暴力）带到了第三层（饕餮——因为我现在对 spack 安装的软件包有了贪婪的胃口，以及它们所需的放纵的依赖项数量）。

  • 定义明确的软件包规范和可靠的具体化。

  • 具体化器（尽管存在一些问题）是 Spack 最有帮助的方面。它允许自动依赖管理和可重现性。

在您的工作流程中，Spack 最大的痛点是什么？

  • 令人惊讶的重新具体化、更新环境和删除旧软件包

  • 具有许多变体的内部依赖关系使得软件包文件变得巨大/复杂

  • 更好的并行环境构建。我认为拥有 Slurm 集成会非常好。

  • 目前，在我们的数据库中已有约 2000 个软件包的部署中具体化所需的时间。

  • 没有语言虚拟依赖项使得当编译器不支持它们时，更难拥有用于较新功能的语言填充 (polyfills)。也难以说明您支持哪些编译器版本

  • c++ 语言标准依赖项，构建依赖项爆炸

  • 似乎我们每次都必须指定外部软件包路径，因此如果 Spack 可以检测预安装的库，那将非常好。

为了在明年改进 Spack，我们能做的最重要的事情是什么？

  • 继续进行外联工作、视频、教程、黑客马拉松，无论什么方式来传播声音。

  • Python 作为虚拟依赖项

  • 我仍然不得不应对人们的投诉是“我试图构建一个简单的软件包，Spack 构建了 Python 和 CMake 和和和和……”所以我认为更好地解密外部项（我知道你们正在研究）会很好。

  • 质量保证：更少的功能但标签版本上有非常可靠的 CI，包括软件包。

  • 交叉编译器支持，新的具体化器

  • 文档组织、示例和所有内部功能的显式 API 列表。

  • 新的具体化器，维护者机器人

  • 为每个站点构建大量构建缓存以加速构建。如果有一个云存储库（可以是 AWS、GCP）可以让 spack 托管所有构建缓存，那会很好。

  • 完全有效的回溯具体化器

  • 不要失去动力。

有没有您希望在 Spack 中看到但目前尚未包含的关键软件包？

  • 可能支持新的构建系统，如 Julia / Golang

  • 我希望有一天能为添加 Uintah 软件套件做出贡献

  • moose

  • WRF。我知道它现在包含在开发分支中。

  • 没有什么我们不能快速为自己编写的。

您还有其他评论吗？

  • 这个项目让我喜欢上班。

  • 是的，我喜欢 spack，现在没有它我做不到。

  • 如果 https://github.com/spack/spack-configs 包含更多能源部机器并更频繁地更新，那就太好了。如果计算中心的管理员在某处提供这些文件，似乎并没有很好地向用户宣传。

  • 几乎每年我用 Spack 取得的最大胜利都是“他们修复了去年我抱怨最大的 Spack 问题”，这表明他们非常善于听取用户的意见，所以请保持下去。

  • 保持出色的工作。我将在未来多年继续使用和支持 Spack。

  • 继续保持出色！Spack 是我过去 5 年中最喜欢的工具！

  • 很容易造成版本和特殊构建的真正纠缠。我认为该项目应该努力保持与应用程序开发人员的良好沟通，以便可以更清楚地识别标准或常用/预期的版本和依赖项集

  • Spack 是非凡的，它消除了过去所有为 HPC 软件带来理性的尝试。我鼓励你们提供商业支持。请提供支持层级，以便我们选择适当的支持级别。