在有多个 crate 的工作区里，怎样让一个 crate 的集成测试依赖并运行另一个 crate 的可执行目标，而不是它的库目标？
工作区结构如下。
workspace/
├── rillmere_probe/
│ └── tests/check.rs
└── rillmere_exec/
├── src/lib.rs
└── src/main.rsrillmere_probe crate 把 rillmere_exec 列为 dev-dependency。它的测试还需要启动 rillmere_exec 的二进制文件。以前这样可以正常工作。但 rust-nightly 的 build-layout-v2 改变了文件布局，导致 assert_cmd-2.1.3 找不到 rillmere_exec 的可执行目标。assert_cmd-2.2.2 的诊断信息更明确，是 CARGO_BIN_EXE_rillmere_exec is unset。看到这个，我开始怀疑 assert_cmd 到底支不支持这种情况。应该不只我一个人遇到过吧。有人找到解决办法了吗？
Within a multi-crate workspace, how can a crate's integration tests require and run another crate's exectuable target, rather than its library target?
Here's the workspace structure:
workspace/
├── rillmere_probe/
│ └── tests/check.rs
└── rillmere_exec/
├── src/lib.rs
└── src/main.rsThe rillmere_probe crate lists rillmere_exec as a dev-dependency. Its tests also need to launch rillmere_exec's binary. Previously this worked fine. However, the build-layout-v2 change in rust-nightly rearranged things, leaving assert_cmd-2.1.3 unable to locate rillmere_exec's executable target. The diagnostic from assert_cmd-2.2.2 is clearer: CARGO_BIN_EXE_rillmere_exec is unset. Reading that makes me wonder whether assert_cmd supports this situation at all. I can't imagine nobody else has run into it. Has anyone found a solution?
恐怕只能选这些办法
-
尽量把 main.rs 中的代码移到 lib.rs，据我所知，正式项目通常已经这样做了。让 main.rs 只负责调用。甚至可以让 main.rs 只剩一行调用 :v，这样其他项目更容易使用这些代码
-
手动测试，先构建可执行文件，再运行它，然后通过 std::command 读取错误
I'm afraid the choices are limited to these
-
Shift as much as you can from main.rs into lib.rs (afaik that's already typical in serious projects). Let main.rs merely invoke it. You could even leave main.rs calling a single line :v, making the code easier for another project to use
-
Test it manually by compiling the executable, starting it and inspecting errors through std::command
如果可以依赖 nightly Rust，那么 artifact dependencies(https://doc.rust-lang.org/cargo/reference/unstable.html#artifact-dependencies)应该能让你直接声明对这里所需可执行文件的依赖。
If depending on nightly Rust works for you, artifact dependencies (https://doc.rust-lang.org/cargo/reference/unstable.html#artifact-dependencies) should let you declare a dependency directly on the executable required here.
哦，太好了！这正是我需要的功能。只有这个集成测试要求 nightly，我可以接受。不过我还是希望 crate 的其他部分能用稳定版 Rust 编译。接下来就要想办法在稳定版编译器下跳过这个测试。可能得把整个测试放进独立的 crate。虽然不理想，但也能用。我更喜欢这个办法，而不是把二进制文件里的内容全搬到库里。
Oh, excellent! That's precisely the feature I'm looking for. Requiring nightly for this specific integration test is fine with me. I'd still like stable Rust to compile everything else in the crate, though. That leaves working out how to omit this test with a stable compiler. Perhaps the whole test will need a crate of its own. Less than ideal, but workable. I'd rather do that than relocate everything from my binary into the library.
只有这个集成测试要求 nightly，我可以接受
artifact dependencies 是 cargo 的不稳定功能，而不是 rustc 编译器的。
遗憾的是，cargo 清单没有类似条件编译标志的机制，所以无法只为一个集成测试开启这项不稳定功能，同时让包里的其他 crate 继续兼容稳定版 cargo，因为稳定版 cargo 连这种清单都无法读取。
因此，要用 artifact dependencies，就得把集成测试 crate 放进独立的包，准确说是独立的工作区，让它拥有与其他包分开的 Cargo.toml。
Requiring nightly for this specific integration test is fine with me
artifact dependencies are unstable functionality in cargo, rather than in the rustc compiler.
sadly, cargo manifests have no equivelent of a conditional compilation flag, so enabling that unstable functionality just for an individual integration test while leaving the package's remaining crates usable by stable cargo isn't possible, since stable cargo cannot even read that manifest.
using artifact dependencies therefore means putting the integration-test crate in a seperate package (actually, a separate workspace), giving it a Cargo.toml distinct from those belonging to the remaining packages.
在开发环境里用 docker-compose up 启动所有服务时，我的几个容器会输出几百行又几百行内容。有没有方便的办法过滤这些输出，或者更好一些，让这些服务在 docker-compose up 运行时不要写到标准输出？
看来 D 能与 C 链接。我想用 D 编写 Python 扩展模块。我是不是漏掉了什么原因，导致这种方法根本无法运行？
python 可以这样写。 Python.withPackages (q: with q; [ fastapi ]) Micro 编辑器有类似的机制吗？ 能不能把 micro 编辑器的软件包和插件一起指定？:thinking: 那样会方便很多。
