tools.build.api/uber 使用 EDN 处理 data_readers.cljc -- 应当支持读取条件

Question

data_readers.clj* 的冲突处理程序在合并时读取文件时将文件视为 EDN。当它处理包含读取条件的 .cljc 文件时，这将失败。

RuntimeException No dispatch macro for: ?
	clojure.lang.Util.runtimeException (Util.java:221)
	clojure.lang.EdnReader$DispatchReader.invoke (EdnReader.java:552)
	clojure.lang.EdnReader.readDelimitedList (EdnReader.java:757)
	clojure.lang.EdnReader$MapReader.invoke (EdnReader.java:680)
	clojure.lang.EdnReader.read (EdnReader.java:145)
	clojure.lang.EdnReader.read (EdnReader.java:111)
	clojure.lang.EdnReader.readString (EdnReader.java:67)
	clojure.edn/read-string (edn.clj:46)
	clojure.edn/read-string (edn.clj:37)
	clojure.edn/read-string (edn.clj:37)
	clojure.tools.build.tasks.uber/conflict-data-readers (uber.clj:89)
	clojure.tools.build.tasks.uber/conflict-data-readers (uber.clj:86)

Comments

因为实际上它应该保留合并输出中的条件。

---

实际上并不复杂，因为读取器支持这个功能：:read-cond :preserve

---

谢谢你Sean，在我提到它之后，你在 Slack 上报道了这个问题。

我后来意识到，当我在 repl 中尝试调用 uber 函数时，似乎只在依赖于 aws-api 和 tick，并且我使用 `clj -T:build build` 从命令行运行时会发生这种情况。

以下是错误的最小复制示例
https://gist.github.com/jjttjj/1b3cac66deb6ece27cb05d1f1f493245

---

当前的合并方式很有趣。抛开 repl-only 的问题不谈，在只有值具有条件性的 data_readers.cljc 文件中，它运行得很好，比如

{foo/bar #?(:clj xxx :cljs yyy)}

但对于下面这种情况（这同样是有效的内容）则不起作用

#?(:clj {foo/bar clojure.core/identity})

我不是说上面的方式很好。

我之前以为它会保留原来的内容，但实际却是读取 :clj 部分，因为谁会想要在 uberjar 中使用除了 :clj 以外的其它部分呢？

---

我在这里解决了我的问题。在本地，我依赖于开发别名中的 tools.build 早期版本，那是在这个功能修复之前的 8.3 版本。我以为我通过查看 dependencies 树来检查了这个，但我在某个时候 confuse 了自己，并说服自己我并没有这么做。为此带来的混淆，我深感抱歉。

Answer 1

我认为这个问题已经修复了 https://clojure.atlassian.net/plugins/servlet/mobile?originPath=/browse/TBUILD-32#issue/TBUILD-32

Comments

以上栈跟踪中包含v0.8.3代码链接： https://github.com/clojure/tools.build/blob/0d20256c40b5a6b6adbcbdf7d0c52cf9e22e994d/src/main/clojure/clojure/tools/build/tasks/uber.clj#L85