7

Github Create test to catch duplicate dependencies · Issue #1582 · ZcashFoundati...

 3 years ago
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.
neoserver,ios ssh client

Contributor

yaahc commented 4 days ago

edited

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 on seamare and implements the various lints we export by default
    • cargo-seamare: A binary crate that acts as an external cargo subcommand, depends on seamare and seamare-lints, instantiates the engine, then passes in the list of lints provided by seamare-lints to be run
  • copy the various lint trait definitions defined in guppy into seamare

  • copy the duplicate dependencies lint from diem into seamare-lints/src/duplicate_deps.rs
  • In cargo-seamare: create a LintEngine 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 into seamare-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???
  • Move seamare, cargo-seamare, and seamare-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.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK