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

从我开始写一个跨平台实现并经过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为基础的。

否则，与bash相比，选择Nim、C、Pascal或Go，这种决定我认为只有维护者应该做出。bash的管道最简单。只需要打包脚本，无需针对不同目标进行编译并发布不同的安装包。这比Graal要简单得多。我理解为什么做出这样的选择。不过，Windows的案例确实为选择其他方案提供了论据。

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

为了让这更像一个答案，我想我是在说bash提供了最简单的打包方式，这使得它在最初成为了一个明智的选择，但随着Windows的加入，我们发现bash不够便携，因此我们需要两个实现，在这种情况下，一个是bash，另一个是powershell，或者更便携的语言如Java（与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，这对于这个社区很重要，但我不拥有Mac！两个项目都从Linux创建windows安装程序和Linux二进制文件。还提供了一个docker文件和构建脚本，用于以平台无关和可重复的方式执行此操作。

• 如果选择重写，我建议从mac开始，执行提供的Docker构建，这样可以从同一台机器上覆盖所有3个平台。
• 对于mac构建，两个项目中都没有改动（虽然我并不确定）。
• 如果我们只想做Windows，我们仍然可以Windows系统、Linux系统、使用Docker的Linux系统或使用Docker的mac系统来完成。

所以为了解决这个问题：一个可用的Docker即是所有设置所需，然后调用提供的docker_build脚本能完成所有构建、打包，甚至构建Windows安装程序。

Nim与Rust

两个项目具有相同的功能

Nim
- 使用愉快，因此很好
- 容易学习、阅读、编写，因此很好
- 在zip文件实现中找到错误（我用于规避 TDEP-120） -> 解决了，但不是很好
- 小型社区 -> 不是很好
- 易于交叉编译 -> 很好
- 不是负责任的选择 -> 很差
- 简洁 -> 很好
- VS code支持良好 -> 很好
Rust
- 绑定与纪律，既有好的一面也有坏的一面
- 非常稳固 -> 很好
- 更难编写 -> 不是很好
- 易于阅读 -> 我想还不错
- 使用困难 -> 很差
- 易于交叉编译 -> 很好
- 负责任的选择 -> 很好
- VS code支持良好 -> 很好
- emacs支持一流 -> 除了我，谁会在乎？

尽管Rust更负责任，但我不得不回到Nim实现中来修复几个问题，而那就像是经历完Rust后呼吸到了新鲜的空气。

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

当然，我会继续维护这个包装以及这两个重写，但这就是我停止这方面积极工作的地方。

Answer 4

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

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