Как заставить крейт быть доступным только в зависимости от разработки

Невозможно сделать так, как вы говорите, но вы можете сделать то же самое, немного по-другому. Взгляните на идею Faux о том, как экспортировать тестовые макеты во внешние ящики: https://nrxus.github.io/faux/guide/exporting-mocks.html Я думаю, вы можете сделать то же самое со своими собственными макетами, как хорошо.

По сути, идея заключается в том, чтобы иметь функциональный флаг, который позволяет использовать макеты, созданные вами в вашем ящике. Бывший. функция mocks:

#[cfg(feature = "mocks")]
struct Something { ... }

Определите его в своем ящике Cargo.toml, но не включайте по умолчанию:

[features]
mocks = []
default = []

И используйте свой ящик из другого ящика с макетами, включенными только в разработке:

[dependencies]
my-crate = "1.2.3"

[dev-dependencies]
my-create = { version = "1.2.3", features = "mocks" }

Вы можете использовать cargo tree -e=no-dev -i your_crate. Это напечатает ваш путь зависимости к этому ящику или иначе:

warning: nothing to print.

To find dependencies that require specific target platforms, try to use option `--target all` first, and then narrow your search scope accordingly.

Если этот крейт используется в зависимостях разработки, но не в других местах, или:

error: package ID specification `your_crate` did not match any packages

Если он вообще не используется.

Вы можете создать сценарий, который будет искать warning: nothing to print и error: package ID specification `your_crate` did not match any packages и возвращать ошибку, если ее нет в выходных данных, и запускать его на своем CI или чем-то еще.

Однако обратите внимание, что выходной формат cargo tree никоим образом не гарантирован, поэтому он может сломаться без предупреждения.

После еще некоторого тестирования и внедрения я понял, что ящик следует разрешить не только dev-dependencies по следующим причинам:

• Как отметил @Peter Hall, кто-то может использовать мой ящик в другом ящике, который также является тестовым ящиком. Если бы он был доступен только в dev-dependencies, он не был бы экспортирован.
• Когда я работаю с рабочими пространствами, я хочу, чтобы мой тестовый крейт находился в зависимостях рабочего пространства (таким образом я могу обновлять его только в одном месте), и мы не можем включать dev-dependency в рабочее пространство.

С учетом вышесказанного, мой первоначальный вопрос заключался в том, чтобы действительно «разрушить все, если не в зависимости от разработки», но даже если бы это было возможно, этого не следует делать по вышеуказанным причинам.

Альтернативно можно использовать обходной путь Хаима Фридмана, чтобы гарантировать, что мы не включим зависимость dev-only по ошибке в реальные зависимости крейта.