Powershell 问题

Question

我在 Slack 上一直很积极地讨论 PowerShell Clojure CLI 命令行在 Windows 中引入的问题。Alex Miller 要求描述这些问题，并附上社区反馈，提出一些可能的解决方案，以某种决策表的形式呈现。

虽然我不确定这种格式是否符合 Alex Miller 的要求，但我会尝试这样做
Clojure CLI 问题

在本文档中，我提出了两种可能的解决方案。
- 以 PowerShell 脚本为中心的二进制包装器
- 可移植的二进制重写 bash / PowerShell 脚本

这两种解决方案都需要相对较低的编程工作量，我制作了一些探索性项目。
- Clojure Powerhel CLI 包装器。在 Windows 上进行测试。
- 可移植 Clojure CLI 重写。在 Windows 和 Linux 上进行测试，它证明了可移植解决方案并不难获得。

我希望收到关于这些问题和两个项目的反馈。

相关 jira: https://clojure.atlassian.net/browse/TDEPS-136

Answer 1

FWIW 我早已开始了一个跨平台实现，使用 CLJS 编写并通过 npm 分发。不确定这是否是一个好主意，但鉴于 node 在这些天的广泛应用，它可能成为许多人的选择。

由于在Windows上存在一个令人烦恼的问题，即每次按下CTRL+C时都会弹出提示终止批处理作业 (Y/N)?，所以我放弃了对此项目的开发。我没有找到修复这个问题的方法，这真的很烦恼。不过，Linux和macOS运行正常。

查看https://github.com/thheller/clojure-cli

Comments

感谢您的反馈
是的，这是一个与批处理文件相关的问题，很多人对此都有抱怨。据我所知，除了更换命令解释器外，没有其他解决方案。

Answer 2

我认为一个便携式Clojure CLI包装器的想法听起来不错，但对于大多数平台：Linux、BSD、OSX来说，bash可能实际上是一个更好的选择，因为它只需运行即可，而且速度足够快。无需编译到不同目标，也不需要为32位和64位版本编译，也不必下载适合您平台的版本。

如果GraalVM的原生镜像已经退出预览版，尤其是在Windows上，我个人会倾向于这个方案。根据这个基准测试：https://github.com/chocolateboy/startup-time，它实际上和bash一样快，甚至更快。

根据上述基准测试和这个： https://github.com/bdrung/startup-time，看起来Pascal实际上具有所有中最小的启动时间，其次是C。这表明Nim几乎和C一样快，比Go和Bash都快。

依赖于另一种语言似乎有点奇怪，但另一方面，bash也是另一种语言，尽管不知为何，它似乎不那么奇怪。不过，Windows不支持正确的Bash却是一个真正的遗憾。

如果GraalVM原生镜像在Windows上运行良好，我仍会为它投票。Oracle目前正在积极工作，随着时间的推移，它应该会越来越好。而且我认为Clojure CLI启动脚本所做的任何操作都与Graal兼容。而且这是纯粹的Clojure。

否则，选择 Nim 或 C 或 Pascal 或 Go 而不是 Bash，这是我认为只有维护者应该做出的决定。Bash 管道是最容易的。只需打包脚本，无需为不同的目标编译它并发布不同的安装包。这也比使用 GraalVM 要简单得多。我理解为什么做出这样的选择。Windows 的情况确实为选择其他方案提供了论据。

无论如何，我只是想在这里添加一些基准测试信息，特别是 Graal 原生图片在启动时间方面应该与 Bash 具有竞争力。

为了使这更像是一个答案，我想我是在回答 Bash 提供了所有选项中最简单的打包方式，这使它最初是一个明智的选择，但随着 Windows 的加入，我们发现 Bash 的可移植性不足，因此我们需要两个实现，在这种情况下，一个是 Bash，另一个是 powershell，或者使用 GraalVM 编译器、Nim、或 C 这样更加可移植的语言，这允许单个代码库跨平台工作，但代价是编译和打包流程更加复杂。

Comments

感谢您的反馈。
- 选择 Nim 的一部分决策是能够从一个操作系统进行交叉编译到所有目标。无论如何，任何语言都可以，完整代码只有 3 或 400 行，这无关紧要，可以随时重写。
- 我同意您的观点，Bash 在 Posix 系统上确实非常好。
- GraalVM 看起来是个不错的主意，但是有两个问题
   - 它在 Windows 上还没有准备好投入实际使用
   - 据我所知，无法获取用于调用 java 程序的完整命令行，这在 Windows 上是必须的，以便以 Posix 兼容的方式解释它。我需要在这方面做更多研究。
- 我同意 GraalVM 二进制的启动时间看起来足够好了，二进制大小可能是一个不同的问题，但我们在乎这个吗？
- 最后，我同意您的观点，最终决定在于 Clojure 团队。尽管那里有一点紧迫感。人们每天都在评估工具，也许因为 PowerShell CLI 的不足而放弃这些工具。这可能会影响 deps.edn 项目的采用，至少在 Windows 用户中是这样。

---

ah-a !  https://github.com/profesorfalken/jProcesses 可以获取命令行...

---

我不知道关于 Nim 的这一点。不过，这是一个很好的观点，因为使用本地编译工具链的缺点是构建和打包需求更加复杂。如果 Nim 可以在不需要针对所有平台运行构建步骤的情况下构建和打包，那会使得事情变得更加简单。实际上，我不知道 GraalVM 是否也是这种情况。

---

作为一个测试，我在可移植重写（Linux端）中添加了交叉编译，看起来工作得非常好。

Answer 3

我在现有的 Nim 实现 中添加了 Rust 实现。那一个要比我想象的要复杂，可能是因为我是新手。但一旦运行起来，它确实可以工作！

关于这项工作的更多思考。

关于构建过程复杂性的担忧

交叉编译是解决这个问题的关键。我深入研究了这个问题。尽管我没有做 Darwin，这对于这个社区来说是一个重要的问题，但我没有苹果电脑！两个项目都是从 Linux 构建了 Windows 安装程序和 Linux 可执行文件。还提供了一份 docker 文件和构建脚本，以实现跨平台、可重复的方式完成这些工作。

• 如果选择重写，我建议在苹果电脑上建立，然后执行提供的 docker 构建，这样就可以从同一台机器覆盖三个平台。
• 对于苹果电脑构建，两个项目中的代码都不应该发生变化（尽管我无法确定）
• 如果我们只想做 Windows，我们仍然可以从 Windows、Linux、带有 docker 的 Linux 或带有 docker 的苹果电脑中进行。

为了解决这个问题：一个工作的 docker 就是需要的所有设置，然后调用提供的 docker_build 脚本进行所有构建、打包，甚至构建 Windows 安装程序。

Nim 与 Rust 的比较

两个项目都有相同的功能

Nim
- 使用愉快 -> 良好
- 易学、易读、易写 -> 良好
- 在 zip 文件实现中找到了一个问题（我用来绕过 TDEP-120） -> 绕过但不好
- 社区小 -> 不好
- 易于交叉编译 -> 良好
- 不是负责任的选择 -> 坏
- 简洁 -> 好
- VS code 支持良好 -> 好
Rust
- 束缚与纪律 -> 既有好处也有坏处
- 十分坚固 -> 好
- 较难编写 -> 不好
- 易读 -> 看起来不错
- 工作困难 -> 坏
- 易于交叉编译 -> 良好
- 负责任的选择 -> 好
- VS code 支持良好 -> 好
- emacs 支持出色 -> 虽然与我无关但纵使我也不在乎

尽管 Rust 更负责任，但我不得不回退到 Nim 实现以进行一些修复，而且在使用 Rust 之后的 Nim 在我看来就像是重新呼吸新鲜空气。

Rust 版本显然没有得到像 Nim 版本那样广泛的测试。

当然，我会继续维护和更新这个包装器和这 2 个重写，但这就是我在这件事上停止主动工作的地方。

Answer 4

现在还有一个使用 GraalVM 构建的 Clojure 实现，作为 Linux、Mac 和 Windows 的本地可执行文件： https://github.com/borkdude/deps.clj

在我看来，这是最佳的前进道路。