PowerShell 问题

Question

我一直在Slack上大声讨论PowerShell Clojure CLI命令行在Windows上引入的问题。Alex Miller要求将问题描述出来，辅以社区反馈，并提出某种决策表中的可能的解决方案。

虽然我不确定这种格式是否符合Alex Miller的要求，但我还是试试看。
Clojure CLI 问题

在这份文档中，我提出了两种可能的解决方案。
- PowerShell 脚本的二进制包装器
- bash/Powershell 脚本的便携式二进制重写

这两种解决方案都需要较低的开发工作量，我创建了探索性项目。
- Clojure Powershel 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的管道线是最简单的。只需打包脚本，无需编译它为不同的目标并发布不同的安装程序。这比Graal简单得多。我理解为什么做出了这个选择。Windows的情况确实是一个倾向于其他冠军的理由。

总之，只是想在这里添加一些基准测试信息，特别是Graal本地映像在启动时间方面应该与bash具有竞争力。

为了把这个回答更具说服力，我觉得我是在回答bash提供了所有选项中最简单的包装，这使得它最初成为一个不错的选择，但随着Windows的加入，我们发现bash的可移植性不足，因此我们可能需要两个实现，在这种情况下，一个是bash，另一个是powershell，或者采用更可移植的语言，如GraalVM编写的Java、Nim或C，这将允许单个代码库跨平台运行，但代价是更复杂的编译和打包流程。

Comments

感谢您的反馈。
- 选择Nim的原因之一是能够在单个操作系统上做交叉编译到所有目标。 anyhow，任何语言都可以，完整的代码在300到400行左右，那不算什么，可以随时重写。
- 我同意您的看法，bash在Posix系统上非常好用。
- GraalVM听起来是个好主意，但有两大问题：
   - 它在Windows上的大规模部署还未准备就绪
   - 据我所知，Windows上无法获取用于调用Java程序的完整命令行，这在Windows中以Posix兼容的方式解释时是必需的。我需要在这方面做更多研究。
- 我同意，GraalVM二进制文件的启动时间似乎足够好，但二进制文件大小可能是一个不同的问题，但我们真的关心这一点吗？
- 最后，我同意您的看法，最终决定取决于Clojure团队。尽管这里有一点点紧迫感。人们每天都在评估工具，也许因为Powershell CLI的不足而放弃这些工具。这可能会影响dep.edn项目的采用，至少在Windows用户群中。

---

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

---

以前并不知道 Nim 的这些知识。尽管如此，这确实是一个很好的观点，因为选择原生编译的工具链的一个缺点是构建和打包的需求更为复杂。如果 Nim 能够为所有平台构建和打包，而不需要在每个平台上运行构建步骤，那么这可以使事情变得容易得多。实际上，我不清楚 GraalVM 是否也是如此。

---

作为一个实验，我在可移植的重写（Linux端）中添加了交叉编译，看起来效果非常好。

Answer 3

我在现有的Nim 实现中添加了一个Rust 实现。这比我想的要复杂得多，可能是因为我是一个新手。但一旦它工作，它确实工作了！

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

对构建过程复杂性的担忧

交叉编译是解决这个问题的关键。我对此进行了深入研究。虽然我并没有进行 Darwin（本社区的一个重要项目），因为我没有苹果电脑！这两个项目都在 Linux 上创建了 windows 安装器和 Linux 二进制文件。还提供了一个 Dockerfile 和构建脚本来实现跨平台、可重复的方式。

• 如果您选择重写，我建议从 Mac 上构建，并进行提供的 Docker 构建，从而从同一台机器上涵盖所有三个平台。
• 对于 mac 构建，对两个项目中的代码没有变更（尽管我并不完全确定）
• 如果我们只想做 windows，我们仍然可以从 windows、linux、使用 Docker 的 linux 或使用 Docker 的 mac 中进行。

为了解决这个问题：一个工作的 Docker 是所需的全部设置，然后调用提供的 docker_build 脚本即可完成所有构建、打包，甚至构建 windows 安装器。

Nim 与 Rust

这两个项目都有相同的功能

Nim
- 与其合作是一种乐趣 -> 优点
- 容易学习、阅读、写作 -> 优点
- 在 zip 文件实现中发现了 bug（我用来绕过 TDEP-120） -> 绕过去了，但不理想
- 社区规模小 -> 不好
- 容易交叉编译 -> 优点
- 并不是一个明智的选择 -> 缺点
- 简洁 -> 优点
- VS code 支持良好 -> 优点
Rust
- 束缚与纪律 -> 两好一坏
- 非常坚固 -> 优点
- 更难编写 -> 不好
- 可读性良好 -> 达到预期
- 合作起来令人痛苦 -> 缺点
- 容易交叉编译 -> 优点
- 是一个明智的选择 -> 优点
- VS code 支持良好 -> 优点
—— Emacs 的支持非常好 —— 谁在乎，除了我？

虽然 Rust 责任感更强，但我还得回到 Nim 的实现中做一些修复，而且这就像是呼吸新鲜空气一样，在 Rust 之后。

与 Nim 版本相比，Rust 版本显然没有经过那么广泛的测试。

我当然会继续维护这个包装器和这两个重写，使其保持更新，但我会在这里停止对这项工作的积极投入。

Answer 4

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

在我看来，这是最好的发展路径。