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的广泛分布，这可能为很多人提供一个选择。

由于在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 编译、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 可执行文件。还提供了一个 Dockerfile 和构建脚本来以平台无关、可重复的方式执行此操作。

• 如果选择重写，我建议从苹果电脑上构建，进行提供的 Docker 构建，这样就可以从同一台机器上覆盖三个平台。
• 对于苹果电脑的构建，这两个项目的代码应该不会有变化（尽管我不能完全确定）
• 如果我们只做 Windows，我们仍然可以从 Windows、Linux、使用 Docker 的 Linux 或使用 Docker 的苹果电脑做。

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

Nim 与 Rust

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

Nim
- 与之合作愉快 - 好
- 学习、阅读和编写容易 - 好
- 在zip文件实现（我用它来规避TDEP-120）中发现了bug -> 绕过它了，但并不是很好
- 小型社区 -> 不太好
- 容易交叉编译 -> 好处
- 不负责任的选择 -> 坏处
- 简洁 -> 好处
- VS代码支持很好 -> 好处
Rust
- 绞索与纪律 -> 两者都好，也不太好
- 非常牢固 -> 好处
- 更难编写 -> 不太好
- 可读性强 -> 我想是吧
- 使用起来痛苦 -> 坏处
- 容易交叉编译 -> 好处
- 负责任的选择 -> 好处
- VS代码支持很好 -> 好处
-emacs支持一流 -> 除了我谁会在乎？

尽管Rust更加负责任，但我在做几个修复时不得不回归到Nim实现，而且在使用Rust之后，这感觉就像是重新呼吸了新鲜空气。

与Nim版本相比，Rust版本显然没有得到充分的测试。

我当然会继续维护和更新这个包装软件以及这两个改写版本，但这是我停止积极工作的地方。

Answer 4

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

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