feat: Use workspace inheritance for dependencies #1645

[hanbu97]

Try to pass CI

[hanbu97]

#1645

[hanbu97]

CI script for Test arm with no gpu using given cargo version nightly-2022-05-09 not support workspace-inheritance

#!/bin/bash -eo pipefail
cargo +nightly-2022-05-09 -Zpackage-features test --release --all --verbose --no-default-features

[vmx]

I haven't done a full in-depth review yet, I just had a quick look.

I don't know what the best practices around having those workspace inheritances. My idea would've been to only move dependencies up to the workspace that are shared between crates. E.g. flate2 is only used by one crate, so I'd leave it there.

Thanks for grouping the dependencies into categories. I first liked the idea. But I'm not sure how usable that is. Perhaps it's easier to just have them alphabetically sorted. I'd fear that it would be hard to keep things within their respective category when new dependencies are added.

When it comes to formatting, I think it's easier if a dependency is kept in a single line. That makes search and replace easier.

I guess it makes sense to put the features into the workspace level, if all crates use the same ones, and leave it to the crate level if they differ. Some crates enable the blake2s feature of filecoin-hashers some don't, so I guess they should be defined on a crate level.

As we can already see that there are many ways to organize it, it might make sense to add a section to the readme about which rules apply. Things like (the ones I propose, but those are not set in stone, I'm happy to have discussion), having the dependency in the workspace only if it is used by more than one crate, sorting them alphabetically, specify features on the workspace level only if all crates use the exact same features etc.

[vmx]

CI script for Test arm with no gpu using given cargo version nightly-2022-05-09 not support workspace-inheritance

I don't think nightly is needed anymore, it might be worth trying out with the same versions the other jobs use. This sounds like a separate PR though. Would you mind opening an issue/PR about it, so that we can track that?

---

In my last comment I forgot to thank you for looking into this, this is surely a bit of work, thanks!