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

顺便说一句，我之前开始了一个跨平台实现，用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的一部分原因是它可以支持从单一操作系统到所有目标平台的交叉编译。 无论如何，任何语言都可以，完整的代码在3到400行左右，这没有什么大不了的，而且可以随时重写。
- 我同意您的看法，bash在Posix系统上很好用。
- GraalVM听起来是个好主意，但有两个问题：
   - 它在Windows上还没有准备好进入主流市场。
   - 根据我所知，无法获取用于调用Java程序的全局命令行，这在Windows上是必须的，以便以Posix兼容的方式解释它。我需要在这方面做更多研究。
- 我同意GraalVM二进制启动时间看起来足够好，但二进制大小可能就是另一回事了，但是我们真的关心这个吗？
- 最后，我同意您的看法，最终决定取决于Clojure团队。尽管这里有一些紧迫感。人们正在评估工具，并且由于Powershell CLI的不足，每天可能会摒弃这些工具。这可能会影响deps.edn项目的采用，至少在美国人群中是这样。

---

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 vs Rust

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

Nim
- 令人愉快的合作 -> 好
- 易于学习、阅读、编写 -> 好
- 在zip文件实现中发现了错误（我用来绕过TDEP-120） -> 解决了这个问题，但并不好
- 小型社区 -> 不好
- 易于交叉编译 -> 好
- 并非最佳选择 -> 差
- 简洁 -> 好
- VS code支持良好 -> 好
Rust
- 约束和纪律 -> 两好一坏
- 牢固可靠 -> 好
- 写作更困难 -> 不好
- 可读性尚可 -> 大概还行
- edges to work with -> 差
- 易于交叉编译 -> 好
- 负责任的选择 -> 优秀
- VS code支持良好 -> 好
- emacs 支持非常出色 -> 除了我还有谁在乎呢？

尽管 Rust 更加负责任，但我不得不回到 Nim 实现中进行几个修复，而在 Rust 之后的 Nim 实现就像呼吸新鲜空气一样。

Rust 版本明显没有 Nim 版本测试得那么全面。

当然，我会继续维护和更新这个包装器和这两个重写，但我将停止对这个项目的主动工作。

Answer 4

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

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