Dependency Hell

[AgeManning]

It is ideal to try and group common code between lighthouse and anchor.

However, we don't want to pull the entire world of lighthouse for tiny pieces of shared code. Often the solution is modularize lighthouse into small crates or feature-gate components that we need.

In the initial building of Anchor this process has been slow and we have been simply importing lighthouse crates, but at a significant compile time cost.

Using cargo tree can help see some of the larger crates.

Anything that pulls the eth2 crate is too large.

I will try and list crates that we can try and reduce here as we go, but this issue is to try and significantly reduce the dependency tree where we can.

warp_utils in our http_metrics crate is a good example.

[dknopik]

Anything that pulls the eth2 crate is too large.

In my opinion, we should refactor the eth2 crate instead of avoiding it. Getting rid of the store and lighthouse_network dependencies in there should be feasible, those are the two worst offenders. Afterwards, we could use it to interface with the beacon node.

[dknopik]

For someone motivated to work on this:

Further possible approaches to combat dependencies are:

• See latest comments in Modularize or Simplify the eth2 crate lighthouse#6452
• Break down LHs types crate with features
• Pull out certain utilities we use in lighthouse_network. We do not use the "core functionality" of lighthouse_network.
• and more, will add if they come to mind