Planning v2 the horror returns!

[GregBowyer]

Planning is, well kinda complex in this crate, I would know @UebelAndre , @acmcarther, myself and others have hacked on it a lot.

I am wondering if we might want to take a different track, I have been staring at the Facebook equivalent of cargo-raze which uses the following two libs:

• serde-starlark - A cute idea I think can be used to analyze BUILD files, maybe generate them better
• cargo-guppy

Guppy seems like it might be better for many of the complex "queries" we want to run over deps, however before I even try to start on what planning looks like I want to test appetite and get more of a design document together.

Naturally this would be a version 2.x thing

[dfreese]

I've dug a bit into serde-starlark, and would love to see a move to use more of those sorts of tools. I don't think what cargo-raze is doing is unique, and what it's doing is worth a fresh look at what might be available to build on top of. (cargo-gnaw also probably has its own approach)

[UebelAndre]

I love the idea of serde-starlark and think it could drastically simplify rendering which I'm a big fan of. I'm not so sure cargo-guppy is needed but could be wrong. I feel like the use of the resolve graph leaves us with exactly what's needed for a particular build and that there isn't a whole lot more to query. Is there something I'm missing?

[GregBowyer]

I suspect that having the deps as a "database" we can apply queries over might rather drastically simplify much of the planning logic, I think it supports the resolve graph and might also have better handling for the cases where cargo is aware of things that are hard to infer from the metadata.

I could be wrong, but I suspect much of our logic becomes boring "please iter this against a render() with DFS"

[UebelAndre]

I definitely think the planning is overly complicated and feel there's multiple sources of truth here. Ultimately there's a finite amount of data we want to render in each file. A graph data structure sounds like it makes the most sense since that's ultimately what we're rendering. But I still wonder if we don't just use a Map of sorts from a PackageId to the required representation? Then just render everything in the resolve graph (which I believe is more-or-less the change you were trying to make for nearly a year, but a good one IMO).