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上提到这个后在这里报告这个问题

我后来意识到，这似乎是在我同时依赖于aws-api和tick时出现的，并且只在尝试从repl调用uber函数时发生。当我从命令行使用`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 之外的东西呢？

---

我在这里解决了我的问题。在本地，我曾经依赖 dev 别名中 tools.build 的早期版本，这个版本是在 8.3 之前，那时这个问题已经得到了解决。我以为我已经通过查看依赖树来检查了这个，但我在某个地方弄错了，并确信我没有检查。对此造成的混乱表示歉意

Answer 1

我原以为这个问题已经修复了[链接]

Comments

在此上面的堆栈跟踪中，您可以看到v0.8.3的代码链接： https://github.com/clojure/tools.build/blob/0d20256c40b5a6b6adbcbdf7d0c52cf9e22e994d/src/main/clojure/clojure/tools/build/tasks/uber.clj#L85