Guppy for crates universe or avoiding the sins of the past

[GregBowyer]

Hi there

Some moons ago I discussed moving cargo-raze to using guppy as a means to work out what the dependency graph looks like.

I would be ok doing this work within the newer rules in rules_rust. I feel that maintaining the "planning" or working out the dep graph directly is a mistake, its none trivial and starts breaking down quickly.

I would be ok trailing a PoC of using guppy here, thoughts?

[illicitonion]

Thanks for starting this discussion!

I'd be interested in taking a look at what a proof of concept would look like. I agree that centralising the core planning work into one place we can re-use it across tools makes a lot of sense.

I think the goal should be 1:1 BUILD file generation as the existing logic - we're reasonably confident the existing generated BUILD files mostly work (though I'm not going to claim confidence in them being "correct"), and so any differences at all would be interesting and worthy of discussion. Ideally, I'd love to see any differences framed as bug reports as to why rules_rust is currently incorrect.

The biggest area I'd be concerned about (which maybe would be something to eagerly try out early on) is around target-specific features (#1710) - cargo metadata doesn't currently output enough information to understand target-specific features (see rust-lang/cargo#9863) so we had to implement support for this via multiple calls to cargo tree. guppy's README states "depending only on the stable cargo metadata format", which makes me wonder whether it correctly models these dependencies - hopefully the tests added in #1710 are sufficient to verify guppy's behaviour here before even trying to do any integration :)