クレートのversionはworkspace設定に、featureはpackage設定に

[qryxip]

内容

Cargo.tomlのdependenciesについて、

1. versionはworkspace.dependenciesに
2. featuresはpackageのdependencies系に

書くようにします。

1.についてはrust-lang/cargo自体がやっています。

2.については、次のコマンドが通るようにfeaturesの補足も行いました。

❯ find ./crates/ -name Cargo.toml -exec cargo clippy --manifest-path {} ';'
❯ find ./crates/ -name Cargo.toml -exec cargo clippy --manifest-path {} --all-targets ';'

関連 Issue

その他

[qryxip]

chronoはC APIとJava APIで使っているが、Java APIだけ無駄にdefault featuresをオンにしていたためそれを削った結果。

[qryxip]

Python APIはpyo3-logのため、Java APIはandroid_loggerのためにtracing/logを有効化する必要があるため、2.の方針によりtracingを明示的に依存に入れるようにした。

[Hiroshiba]

LGTM！！

workspaceに書いてる依存が、package側のビルドのタイミングで全部入ってくる、というわけじゃないんですね！
（poetryとかはrootの設定を.devなどが勝手に参照するはず）

[Hiroshiba]

たぶん問題ないのでマージしようかなと思ったのですが、レビュワーに @sevenc-nanashi さんが指名されていました。
こういう時って @sevenc-nanashi さんのレビューを待った方がいいでしょうか？ 👀

（@sevenc-nanashi さん、@qryxip さんどちらの意見も聞くのが良さそう）
（ヒホさんがマージで良さそうと思ったらマージ、とかでも全然良いと思います 🙏 ）

[sevenc-nanashi]

自分は別に大丈夫です。

[qryxip]

このPRの場合気をつけるべきはhttps://github.com/VOICEVOX/voicevox_core/pull/688/files#r1399498252のようなものかと思っています。

これはどういうことなのかというと、featureって通常APIの存在をon/offするために使われ、「デフォルトの挙動」の変更はすべきではないとされているのですが、tracing/logはその例外になります。tracing/logをオフにしてしまうとtracingのログがlogのログへの自動変換がされなくなり、pyo3-logやandroid_loggerに何も流れなくなってしまいます。そして現状そういうことが起きてもそれに対するテストはまだ無いはずです。
(対してAPIが消える分にはコンパイルが通らなくなるだけなので問題無い)

そういう観点のレビューを頂けるなら待った方がよいのかなと思うのですが、このあたりRustのエコシステムの土地勘が必要でもあると思うので、そこを要求するのはという気もしています。なので方針自体の合意ができればそれでいいのかなと思っています。

[Hiroshiba]

なるほどです！！！
完全に理解したわけではないのですが、気をつけないといけないということはなんとなく把握しました。
issue作っても良いかも？

[Hiroshiba]

問題ないと思うのでマージします！！