PowerShell难题

Question

我在Slack上关于由Windows上Clojure CLI命令行引入的问题发表了大量评论。Alex Miller要求描述这些问题，增加社区反馈，并以某种决策表的形式呈现可能的解决方案。

虽然我不确定格式是否符合Alex Miller的要求，但以下是内容
Clojure CLI问题

在此文档中，我提出了两种可能的解决方案。
- 在PowerShell脚本周围的二进制包装
- 可移植的二进制脚本重写

这两个解决方案都需要相当低的编码工作，我已经产生了探索性项目。
- Clojure Powershel CLI包装器. 在Windows上测试。
- 可移植Clojure CLI重写 . 在Windows和Linux上测试，它证明了可移植解决方案并不是难以获得。

我期待收到关于提出的问题和这两个项目的反馈。

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

Answer 1

FWIW，我之前就开始用CLJS编写了跨平台的实现，并通过npm进行分发。虽然不确定这是否是个好主意，但鉴于这些年被广泛使用的Node.js，这可能是很多人的一种选择。

我差不多停止了这方面的工作，因为Windows上有一个令人烦恼的问题，每次按CTRL+C都会弹出“Terminate batch job (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，帕斯卡的实际启动时间可能是所有语言中最小的，其次是 C。它显示 Nim 几乎和 C 一样快，比 Go 和 Bash 快。

似乎依赖另一种语言确实有些奇怪，但另一方面，bash也是一种语言，虽然不知为什么，依赖它似乎不那么奇怪。然而，Windows不支持合适的bash确实是一件遗憾的事情。

如果GraalVM原生镜像在Windows上足够良好，我仍会选择它。随着Oracle对它的积极投入，它应该会随着时间的推移而不断改进。我不认为Clojure CLI启动脚本所做的一切无法与Graal兼容。并且它是完完全全的Clojure。

否则，用Nim、C、Pascal或Go代替bash而不是bash的决定，我认为只有维护者应该做出。bash的管道操作最为简便。只需打包脚本，无需为不同的目标编译，也不需要发布不同的安装程序。这比GOR更快。我理解为什么做出这个选择。但是Windows的情况确实提出了一个偏向其他选择的理由。

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

为了使这个答案更有说服力，我猜想我是在回答bash为所有选项提供了一个最简单的打包方式，这使得它最初是一个合理的选择，但是当Windows加入这个因素后，我们看到了bash并不足以跨平台，因此我们可能需要两个实现，在本例中，一个在bash中，一个在powershell中，或者使用Java、GraalVM编译、Nim或C等更便携的语言，将允许单个代码库跨平台工作，但代价是更复杂的编译和打包流程。

Comments

感谢您的反馈。
- 选择Nim的部分原因是能够从单个操作系统跨编译到所有目标。无论如何，任何语言都可以，完整代码在3或400行左右，这不算什么，可以随时重写。
- 我同意您的观点，bash在Posix系统上非常好。
- GraalVM听起来是个好主意，但有两个问题：
- 它在Windows上尚未准备好投入实用
- AFAIK，目前无法获取用于调用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构建，并从同一台机器上涵盖所有三个平台。
• 对于mac构建，两个项目中的代码都不应该有任何改变（尽管我并不是非常确定）。
• 如果我们只想做Windows，我们仍然可以从Windows、Linux、带有docker的Linux或带有docker的mac执行。

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

Nim 与 Rust

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

Nim
- 搭配愉快 -> 不错
- 容易学习、阅读和编写 -> 不错
- 发现了 zip 文件实现中的bug（我使用它来规避 TDEP-120）-> 环绕问题但不太好
- 社区规模小 -> 不太好
- 跨平台编译容易 -> 不错
- 不是最佳选择 -> 不佳
- 简洁 -> 不错
- VS 代码支持良好 -> 不错
Rust
- 让人感受到束缚与纪律 -> 两面性
- 巩固性强 -> 不错
- 编写难度大 -> 不太好
- 易读 -> 好吧我想
- 使用起来痛苦 -> 不好
- 跨平台编译容易 -> 不错
- 是负责任的选择 -> 好的
- VS 代码支持良好 -> 不错
- Emacs 支持非常好 -> 又只有我在乎吗？

虽然 Rust 责任更大，但我不得不回到 Nim 实现去进行几个修复，并且那是一种在 Rust 之后的如释重负。

Rust 版本显然没有 Nim 版本测试得那么彻底。

我当然会继续维护这个包装器和这些两个重写，但我会在那里停止对这个项目的工作。

Answer 4

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

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