2024 Clojure 状态调查! 分享您的看法。

欢迎!请查看 关于 页面以了解更多此网站的运作方式。

+1 投票
tools.build
重标记

我正在开发一个依赖于 tools.build 的库,并希望将其发布为jar包。由于 tools.build 只作为 git 依赖项提供,我无法将其包含在 pom 文件中作为依赖项。关于此主题的更广泛讨论在 Slack 线程 中进行,其中 @alexmiller 请求我在此处提出此话题。

2 个回答

+2 投票
我不确定这是否是正确的问题?
是的,抱歉,我抓错了链接
0

除了Alex使用的在tools.build之上构建的场景外,还有其他原因可以使.jar文件有用。

精确可重现在是考虑这一点的另一个原因。如果有人希望在美国开发用于航电系统产品,他们需要符合FAA的DO-178C...我不是律师,但我的理解是,一项要求是能够在设备生命周期内生产软件的二进制精确副本,这可能是在他们被批准后几年。我不做这类工作,但我做一些支持这类工作的事情。对clojuretools.build等工具的微小更改可能会对输出的精确代码、执行的指令数量、分配的内存量等产生影响。在这种情况下,即使是微小的向后兼容性更改也是无法容忍的。其他领域如机器人或卫星也可能会对可重复性有类似的要求,我怀疑美国不是唯一有这类规定的国家。

MAVEN坐标是一个更具不变性的事物,并且随着时间的推移,它有更好的记录以为您提供完全相同的工件。

精确的Git提交是可靠的(可能也是大多数项目的最佳选择),但Git历史可能会被修订或删除...Git "发布"甚至更不可变。它们可以被移动(例如,从github到gitlab),甚至标签也可以被移动。如果您在思考未来五到十年,当项目维护者可能改变一两次时,这些想法会变得更加可怕。

by
Clojure 在编译代码方面本身就缺乏可重复构建,因此 tools.build 的 JAR 文件对这个问题的作用不大。如果需要的是“二进制精确复制”,Clojure 被排除在外。
by
听起来似乎并不是从源代码的二进制精确可重复性,而是关于部署。一旦构建完成,JAR 将始终保持一致(即使它只包含 Clojure 源代码)。

话虽如此,我还是很好奇,Clojure 构建的是什么阻止了从源代码中进行可重复性?我知道 JAR 不是,因为文件上有关时间戳之类的元数据,但这可以移除,JAR 的内容仍是可重复的。
by
看起来已经完成了!谢谢大家! https://search.maven.org/artifact/org.clojure/tools.build/0.8.4/jar

> 在编译代码方面,Clojure 已经没有可重复构建了

我认为针对相同源代码应用特定版本的 Clojure 将始终生成相同的输出。(除非有人在编译任务中引入时间/随机种子?)

> 我很好奇,Clojure 构建的是什么阻止了从源代码中进行可重复性?

老实说,我也是。但话又说回来,如果我们有一个可以指向的不可变资产,我们就减少了可能引起非确定性的因素的集合。
...