You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During updates to v0.11 branch, we decided to revert a few feature PRs to facilitate merging #5127 into master. This PR is tracking reintroduction of the feature, improvements, and updates from @mcdee.
I'll own this as a high priority item this week and work with @mcdee to ensure these changes land in master. There was some offline discussion about rationale behind the reversions and ultimately we want to accept these features while unblocking everyone in development.
One of the key things that was pointed out that there exists a reimplementation of several Prysm / eth2 methods in github.com/wealdtech/go-eth2-types due to the organization and dependencies of a large project like Prysm. We've also heard from other downstream users (#5130) that Prysm is difficult to build upon due to it's project structure and use of patches, particularly related to ethereumapis. Given that github.com/prysmaticlabs/ethereumapis is unlikely to be accepted as a canonical source for ethereum API definitions, we should reconsider our patch approach and general avoidance on ssz specific information in ethereum APIs.
Lastly, I would like to reevaluate Prysm's dependency management to leverage go modules to Prysm more available to downstream users. I'll follow up with a design proposal for reorganizing Prysm, its dependencies, and certain helpful types for downstream users.
The text was updated successfully, but these errors were encountered:
@prestonvanloon RE: dependency management and Go modules. If you're not already aware, Bazel supports Go Modules with Gazelle. For example, I've been using
bazel run //:gazelle -- update-repos -from_file=go.mod
to integrate a fork of go-eth2-wallet. This approach is still susceptible to the patches you mentioned though.
5260 was the update to 0.10; I opened another PR for 0.11 but it wasn't merged. Easiest thing to do here is to open a new PR that has both sets of changes, I think. If you concur I'll send one in
5236 there are already people using this keymanager in the new testnet, so no longer suitable to remove, and ditto 5249
4984 was an update for the 0.11 functionality. It probably needs to be refreshed given our conversation about the implicit init() that was in go-eth2-types with a newer version of the type (and again as per our discussion would love to be able to replace go-eth2-types entirely with a prysm repo once it gets broken out)
During updates to v0.11 branch, we decided to revert a few feature PRs to facilitate merging #5127 into master. This PR is tracking reintroduction of the feature, improvements, and updates from @mcdee.
I'll own this as a high priority item this week and work with @mcdee to ensure these changes land in master. There was some offline discussion about rationale behind the reversions and ultimately we want to accept these features while unblocking everyone in development.
One of the key things that was pointed out that there exists a reimplementation of several Prysm / eth2 methods in github.com/wealdtech/go-eth2-types due to the organization and dependencies of a large project like Prysm. We've also heard from other downstream users (#5130) that Prysm is difficult to build upon due to it's project structure and use of patches, particularly related to ethereumapis. Given that github.com/prysmaticlabs/ethereumapis is unlikely to be accepted as a canonical source for ethereum API definitions, we should reconsider our patch approach and general avoidance on ssz specific information in ethereum APIs.
Lastly, I would like to reevaluate Prysm's dependency management to leverage go modules to Prysm more available to downstream users. I'll follow up with a design proposal for reorganizing Prysm, its dependencies, and certain helpful types for downstream users.
The text was updated successfully, but these errors were encountered: