请分享您的想法,参加 2024 Clojure 状态调查!

欢迎!请查阅 关于 页面以了解更多关于如何使用本站的信息。

+1
tools.build
重新标记

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

2 答案

+2
by
我不确定这是否是正确的问题?
by
by
是的,对不起,抓取了错误的链接。
0 votes
by

除了Alex在tools.build之上构建的情况,还有其他原因使得.jar文件变得有用。

精确可重现是考虑这个的另一个原因。如果有人想在美国开发用于航空电子设备的产品,他们需要符合FAA的DO-178C...我不是律师,但我理解其中一个要求是能产生与部署到设备上软件完全相同的二进制副本,其生命周期可长达设备批准后几年。我自己不做这类工作,但我做一些支持这类工作的事情。对clojuretools.build等工具的微小改动可能会对产生的/执行的精确代码、执行的指令数量、分配的内存等产生影响。在这些情况下,即使是最小的向后兼容性更改也不能容忍。其他领域如机器人或卫星可能也有类似的可重现性要求,我相信美国不是唯一有此类规定国家。

Maven坐标是更不可变的东西,并且在时间上有一个更完整的记录,可以为您提供完全相同的软件包。

精确的git提交是可靠的(可能是大多数项目的最佳选项),但git历史可以被修改或删除... Git“发布”甚至更易变。它们可以被移动(例如,从github到gitlab),标签也可以被移动。如果考虑到5年或10年后的未来,那时项目维护者可能已经换了一两次,这些想法就会显得更加令人担忧。

Clojure在编译代码方面本身就缺乏可重复构建,因此tools.build的JAR与此问题无关。如果要求是“二进制精确重复”,那么Clojure则被排除在外。
听起来更像是二进制精确的从源代码的可重复性,但针对部署。一旦构建了Jar,它总是会是相同的(即使它只包含Clojure源代码)。

话虽如此,我很好奇,Clojure构建中哪些方面是从源代码不可重复的?我知道Jar不是,因为文件上的元数据(如时间戳)等,但这可以移除,Jar的内容仍然是可重复的。
看起来已经完成了!谢谢大家! https://search.maven.org/artifact/org.clojure/tools.build/0.8.4/jar

> 从编译代码的角度来看,Clojure已经没有可重复构建。

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

> 我很好奇,Clojure构建中哪些方面是从源代码不可重复的?

说实话,我也有同样的疑问。但话虽如此,如果我们有一个不可变的资产可以指向,我们已经减少了可以引入非确定性的因素集合。
...