Make use of workspace dependencies #692
Conversation
This allows us to define several crate dependencies in a single place: https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table Signed-off-by: Daiki Ueno <ueno@gnu.org>
ueno
force-pushed
the
wip/dueno/workspace-dependencies
branch
from
68ec566 to
2a2de2d
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
| # wiremock was moved to be a regular dependency because optional | ||
| # dev-dependencies are not supported | ||
| # see: https://github.com/rust-lang/cargo/issues/1596 | ||
| wiremock = {version = "0.5", optional = true} |
There was a problem hiding this comment.
Any reason why zmq and wiremock are out of the inheritance?
There was a problem hiding this comment.
I think because they are used only in keylime-agent, not shared with the other parts (keylime and keylime-ima-emulator)
There was a problem hiding this comment.
The reason behind this is that the top-level workspace.dependencies can't include optional dependencies, as described at https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table
There was a problem hiding this comment.
@ueno I can be confused here, so bare with me. But IIUC this is valid:
zmq = {workspace = ture, optional = true}
See for example https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace
You are right that we cannot do this in the top level, in [workspace.dependencies], where all the dependencies are listed, but I am not sure how relevant is that. For example, if a consequence of doing this is that during vendoring the optional crates will always be included.
5 participants
This allows us to define several crate dependencies in a single place: https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table