Use cargo's workspace.package and workspace.dependencies

[flub]

This switches to use cargo's new workspace.package and
workspace.dependencies features. It reduced duplication in the cargo
files.

A number of dependency versions where unified through this already.

[Arqu]

Holly molly, didn't know this was a thing. A+++ for this.
Question, is there a CI check we can integrate to catch these. Seems like it will be hard to maintain long term.

[flub]

Holly molly, didn't know this was a thing. A+++ for this.

It's pretty new, I think 1.64. So only the merging of quic-rpc bumping MSRV to 1.65 enabled us to use this.

Question, is there a CI check we can integrate to catch these. Seems like it will be hard to maintain long term.

You mean catching a dependency added to a crate's [dendencies] table rather than the workspace's [workspace.dependencies]? Not unless we write some kind of script ourself· I guess this isn't too difficult: parse the Cargo.toml, check the things inside the dependecies table that they all have a workspace: true in them.

Though I'm not sure how much of a problem it will be: if we consistently use them it should be pretty obvious in code review that it's forgotten. So my instinct would be to try it first without enforcement and only later add enforcement if it turns out it is needed.

[flub]

i realise this example still needs cleaning up. i'll do this once there's approval in principle. this might also race the iroh-embed pr - so one of them will need fixing up anyway. and examples are touched by that pr

[dignifiedquire]

I am concerned about a couple of things here

• tooling support for this, need at least cargo add, cargo tree, cargo outdated and cargo release fully working
• enabling unnecessary features: each crate should only enable the features it absolutely needs, as it might be used independently of the other crates in the workspace
• maintainability: this makes it considerably harder to look at & understand the dependencies of a single crate, especially when working on sth in isolation

[flub]

I am concerned about a couple of things here

* tooling support for this, need at least `cargo add`, `cargo tree`, `cargo outdated` and `cargo release` fully working

• doing a cargo add of a package already in the [workspace.dependencies] table results in the right thing: *pkgname.workspace = true is added to the crate where cargo-add is invoked.
• cargo tree just keeps working.
• cargo outdated does not: Support workspace inheritance kbknapp/cargo-outdated#325 (to be honest, I didn't even know of this one!). cargo-udeps is already fixed.
• cargo release is part of rust itself, so I assume this works - it is a bit hard to just try.

* enabling unnecessary features: each crate should only enable the features it absolutely needs, as it might be used independently of the other crates in the workspace

Absolutely, and this is still possible. I think this is mostly a policy thing though and why I wrote down how I decided what feature to put where. To keep minimal perhaps the policy should change that by default as little features as possible are enabled in the [worspace.dependencies] table, only those that we explicitly want everywhere like e.g. anyhow's backtrace.

Happy to make that change if we prefer. I couldn't decide myself here what was easier to work with.

* maintainability: this makes it considerably harder to look at & understand the dependencies of a single crate, especially when working on sth in isolation

Not sure I really agree. You look at that crate's Cargo.toml and see all the dependencies. If we change how we select features to also be primarily in the crate Cargo.toml files then all information is there other than the version number. Which seems practical enough.

[dignifiedquire]

https://github.com/crate-ci/cargo-release is not a part pf cargo

[flub]

https://github.com/crate-ci/cargo-release is not a part pf cargo

fair enough, anyway - supported since v22 on 21 Oct 2022: https://github.com/crate-ci/cargo-release/releases/tag/v0.22.0

[dignifiedquire]

haven’t reviewed every line, but lets try it out, if it doesn’t work we can always revert it