c.t.n.move: 不支持移动 .cljc 文件

Question

看起来 c.t.n.move 没有得到任何读取条件的爱。我使用这个命名空间来支持 https://github.com/benedekfazekas/mranderson 文本：mranderson）：一个源嵌入工具，用于 cider-nrepl 和 refactor-nrepl，以避免与用户正在工作的代码/项目冲突。最近，我们开始为 refactor-nrepl （好吧，tools.namespace 自己）添加依赖关系，这可能使用 .cljc 文件。对于这些源文件，源嵌入开始失败。

Answer 1

评论由：stuart.sierra 提供

好主意——很高兴看到人们在其他开发工具中使用 tools.namespace。

这能否进一步扩展到以 '平台' 作为参数，如 {{c.t.n.find}} 或 {{c.t.n.dir}}？

（我故意排除了 {{c.t.n.move}} 以限制 0.3.0 中更改的范围，但是您的补丁证明这可能并不难进行更改。）

Answer 2

评论由：benedek.fazekas 提供

第一个补丁做了您要求的事情，我希望如此。为了向后兼容，保留了 {{move-ns}} 的原始签名：默认使用 {{clj}} 平台。

第二个补丁更进一步：如果未提供平台，将尝试基于旧符号的文件扩展名猜测它。您可能认为这有点过度复杂：如果您愿意，可以选择第一个补丁。

Answer 3

评论由：stuart.sierra 提供

感谢您对这些补丁的工作。我进行了一些更多的测试，并发现了更多的问题。

猜测文件扩展名会导致不可预测的结果，因为您不知道哪个文件会被移动。例如，对于在ClojureScript中使用{{:require-macros}}的情况，同一个命名空间可能会同时存在{{.clj}}和{{.cljs}}版本，这是很常见的。

不幸的是，即使指定“平台”参数也不能完全解决问题，因为在同一时间您可以同时有{{.cljc}}文件、{{.clj}}和{{.cljs}}文件。这可能不常见，但在(a链接：http://dev.clojure.org/display/design/Reader+Conditionals)中明确指出，这是读者条件设计的一部分）。例如，一个库可能有一个平台无关的{{.cljc}}文件，并用特定平台的文件覆盖它。在这种情况下，即使指定了“平台”参数，您仍然无法控制哪个文件被移动。

因此，现在我认为像“移动命名空间”这样的操作的唯一合理方式是移动定义该命名空间的所有文件，保留它们的文件扩展名。这在用户视角上似乎也是人们想要的。

因此，{{move-ns}}应该接受新旧符号，找出所有匹配的文件（任何扩展名），在保留扩展名的情况下移动/重命名它们，然后对所有{{.clj}}、{{.cljs}}和{{.cljc}}文件应用文本转换。

如果我们正在搜索文件，那么我们可以消除指定源路径的必要，这也与TNS-39有关。

Answer 4

评论由：benedek.fazekas 提供

我并没有放弃这个问题或补丁，但似乎这与支持多平台项目的一个更大的问题有关，因此也与TNS-38有关。

我还在考虑更广泛的环境：{{move-ns}}不仅用于mranderson的源内联，还用于refactor-nrepl功能((a链接：https://github.com/clojure-emacs/clj-refactor.el/wiki/cljr-rename-file-or-dir)),它基本上使用TNS的其他部分重新实现了这个功能。

mranderson的故事对我来说是关于探索不同的依赖处理方式，那里有一个好的(a链接：https://skillsmatter.com/skillscasts/7251-lightning-talks-day-2)，由Glen Mailer概括了clojureX今年的问题。我的想法是创建本地、深层嵌套的依赖，也许可以增强ns宏以能够加载它们——甚至不确定这是否可行。这将消除源内联的需要，并且更重要的是，我认为这将是一个更卫生的方法。

希望这能理解。对于这显然超出这个条目范围的脑容量，我感到抱歉。

Answer 5

参考: https://clojure.atlassian.net/browse/TNS-37 (由 benedek.fazekas 报告)