PowerShell烦恼

Question

我在Slack上很大声地讨论了PowerShell Clojure CLI命令行在Windows中引入的问题。Alex Miller要求描述这些问题，并附上社区反馈，并在某种决策表中展示可能的解决方案。

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

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

这两种解决方案都需要较低的编码工作量，我制作了一些探索性项目。
- Clojure PowerShell CLI包装器。在Windows上进行测试。
- 便携式Clojure CLI重写。在Windows和Linux上进行测试，证明了便携式解决方案并不是那么难弄到。

我希望收到关于这些问题以及这些建议项目的反馈。

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

Answer 1

供参考，我之前用Clojure脚本语言编写了一个跨平台实现，并通过 npm 进行分发。虽然不确定这是否是个好主意，但考虑到现在node.js的广泛应用，这也许会成为许多人的选择。

因为这个在Windows上令人烦恼的问题，我停下了对此的工作：在每次按 CTRL+C 时都会弹出一个询问“中止批处理作业（是/否）？”的对话框。我没有找到解决方案，非常让人厌烦。不过，Linux/macOS上运行正常。

参见 https://github.com/thheller/clojure-cli

Comments

感谢您的反馈
是的，这是一个与批处理文件有关的常见问题。据我所知，除更换命令解释器外，没有其他解决方案。

Answer 2

我认为可移植的Clojure命令行界面包装器这一想法听起来不错，但对于大多数平台（Linux、BSD、OSX）来说，bash可能是更好的选择，因为它简单有效，且速度足够快。无需针对不同目标进行编译、不需要为平台下载不同版本的软件。

如果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命令行界面启动脚本所做的任何操作都将在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 用户来说是这样。

---

啊哈！https://github.com/profesorfalken/jProcesses 可以获取命令行...

---

不知道Nim的这一特性。不过，这是一个非常好的观点，因为使用本地编译工具链的一个缺点是构建和打包需要更复杂。如果Nim能够在所有平台上构建和打包而不需要在它们下面运行构建步骤，那么这可以使事情变得容易得多。实际上，我并不知道这是否适用于GraalVM。

---

作为一个测试，我在便携式重写中添加了交叉编译（Linux方面），看起来工作得很好。

Answer 3

我在现有的Nim实现中添加了一个Rust实现。这比我想的要难，可能是因为我是新手。但是一旦运行，它确实运行得很好！

关于这个项目的更多思考。

担心构建过程的复杂性

交叉编译是解决这个问题的关键。我深入研究了这个问题。虽然我没有做Darwin，这是这个社区中非常重要的一部分，但我没有苹果电脑！两个项目都是从Linux创建Windows安装程序和Linux二进制文件。还提供了Docker文件和构建脚本，以进行平台无关且可重复的方式构建。

• 如果选择重写，我建议从Mac开始，执行提供的Docker构建，然后从同一台机器上覆盖所有三个平台。
• 对于Mac构建，这两个项目的代码应该都不会发生变化（虽然我难以保证）
• 如果我们只想做Windows，我们仍然可以从Windows、Linux、带有Docker的Linux或带有Docker的Mac上做。

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

Nim与Rust

两个项目都有相同的功能

Nim
- 与之共事是一种乐趣 -> 优秀
- 易学、易读、易写 -> 优秀
- 在zip文件实现（我用它来规避TDEP-120）中发现了一个bug -> 已绕过，但不是很好
- 社区规模小 -> 不是很好
- 跨编译容易 -> 优秀
- 并非最佳选择 -> 差
- 简洁 -> 优秀
- VS代码支持良好 -> 优秀
Rust
- 束缚和纪律 -> 双重优点和缺点
- 稳如磐石 -> 优秀
- 编写更加困难 -> 不是很好
- 易于阅读 -> 大概还不错
- 与之共事很痛苦 -> 差
- 跨编译容易 -> 优秀
- 责任感强 -> 优秀
- VS代码支持良好 -> 优秀
- emacs支持极佳 -> 只有我会在意？

尽管Rust更为负责，但我不得不回到Nim实现中进行一些修复，之后回到Rust就像呼吸新鲜空气一样。

Rust版本显然未像Nim版本那样经过充分的测试。

我将当然会保持包装程序以及这两个重写版本的维护和更新，但在那里我将停止对此项目的积极工作。

Answer 4

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

我认为，这是最佳的前进道路。