Github Create test to catch duplicate dependencies · Issue #1582 · ZcashFoundati...
source link: https://github.com/ZcashFoundation/zebra/issues/1582
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Is your feature request related to a problem? Please describe.
Recently we found a regression in our metrics system in zebrad
. The issue ended up being that we'd accidentally duplicated the metrics
dependency during a recent refactor. The crates on the old version would silently fail to access the exporter when reporting metrics because the variable containing the exporter was duplicated in each version, and only the newer version's global exporter had been initialized.
Describe the solution you'd like
We've already fixed this problem in #1561 but we'd like to prevent this from happening again in the future. The plan is to use guppy
to write a test/lint to catch and report duplicated dependencies are part of our CI process. The author @sunshowers helpfully already pointed me to where they've already implemented this lint for their work codebase (link).
We should more or less vendor this lint into our codebase. If possible we'd also like to do so in a way that is reusable so that other rust projects can utilize this same lint easily.
Design / Mentorship Instructions
TBD
I still need to talk some more with Rain about the design for the reusable version of diem/guppy.rs
. My expectation is that it would look similar to clippy
, but Rain has thought much more about this than I have so I want to get my ducks in a row before I commit to writing out a design.
I've talked to Rain and the plan we came up with is to create a cargo subcommand like clippy
which we've decided to call seamare
that is based on the guppy
code in diem
. This subcommand can then be distributed on crates.io and run in CI.
MVP Checklist
-
create three new crates in
zebra
-
seamare
: The main library that defines the lint engine and traits -
seamare-lints
: A separate library that depends onseamare
and implements the various lints we export by default -
cargo-seamare
: A binary crate that acts as an external cargo subcommand, depends onseamare
andseamare-lints
, instantiates the engine, then passes in the list of lints provided byseamare-lints
to be run
-
copy the various lint trait definitions defined in guppy into
seamare
-
copy the duplicate dependencies lint from
diem
intoseamare-lints/src/duplicate_deps.rs
-
In
cargo-seamare
: create aLintEngine
that loads the package graph via guppy, takes a set of types that implement these various traits, and then executes each of the lints via the traits against the package graph
Additional Goals
-
Have
LintEngine
run all of the lints in parallel -
Copy the rest of the applicable lints that exist in
diem
intoseamare-lints
- Each lint has it's own file
- Each lint has tests (clippy's repo will be useful for inspiration here)
-
Support out of tree lints (Hard, ideas below)
- Create an option in
cargo-seamare
for generating a skeleton project that is essentially a copy of itself, which can then be edited and have new lints added in via source - Support wasm plugins
- dylib plugins???
- Create an option in
-
Move
seamare
,cargo-seamare
, andseamare-lints
into their own organization and repo to consolidate implementations with upstream source
Describe alternatives you've considered
I've not really considered any other alternatives, as far as I know guppy is the exact right tool to solve this problem, and this is what it was designed for.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK