工具构建API/uber使用EDN处理data_readers.cljc -- 应该支持读取条件

Question

data_reader.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上报告此问题

我后来意识到，这在我同时依赖aws-api和tick，并且只在我尝试从REPL调用uber函数时发生。我从命令行使用`clj -T:build build`运行时一切正常。

以下是错误的简化重复
https://gist.github.com/jjttjj/1b3cac66deb6ece27cb05d1f1f493245

---

当前合并的实现方式很有意思。在不考虑 repl-only 问题的前提下，对于只涉及值条件的数据_readers.cljc 文件，这种做法是可行的，例如：

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

但是对于下面这样的（这是有效内容）：

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

我不认为上面的风格很好。

我曾经以为这不会保留原有内容，而是会读取 :clj 分支。因为谁会在 uberjar 中使用除了 :clj 以外的任何东西呢？

---

我弄清楚了我的问题。我本地依赖于 tools.build 的早期版本，在开发别名中，这个版本在 8.3 前被修复。我本以为我在检查依赖树，但我在某个地方弄混了，并坚定地认为自己没有。对此的困惑表示歉意。

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