-
Notifications
You must be signed in to change notification settings - Fork 38
Adapt to new CryptoStore API #148
Adapt to new CryptoStore API #148
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, we have a bit of a cyclic dependency issue here. My suggestion to resolve this is:
- Merge the Substrate PR #8619 that updates the
SyncCryptoStore
API - We will bump the BEEFY Substrate dependency to a commit that does include this PR
- The Polkadot companion PR should be done next
@adoerr instead of using |
@tomusdrw using IMO, the issue here is that a Substrate API ( Now, PR's to use the new version of the Substrate API have been opened, before the API change itself was even accepted to Substrate. IMO those two PR's should have done after the API change has been accepted into Substrate. Or am I missing something here? Maybe, I just don't understand, how this Polkadot companion thing is supposed to work. |
This is more efficient when using a remote signer (see paritytech/substrate#7285)
I don't see a cyclic dependency (BEEFY doesn't depend on polkadot). It seems for now, we'll have to merge such PRs manually (substrate -> beefy -> polkadot). Long-term, merging BEEFY into substrate/polkadot repo would solve this problem (or making bot aware of BEEFY). |
The main problem is that the companion set up was introduced to make sure that random Substrate PRs don't introduce extra work for Polkadot developers - i.e. every change in Substrate that is breaking Polkadot must have a PR (companion PR) that fixes any incompatibilities. This is ENFORCED by Substrate CI - i.e. the build has to be green before you can merge the PR. Now with the way BEEFY is integrated right now, if there is a Substrate change that breaks BEEFY code there is no way to create a Polkadot companion PR that would turn green (there is one, but it requires patching all beefy deps in Polkadot, which is quite cumbersome). So the most straightforward solution is to either:
Long term it's going to be solved by the merge indeed or proper versioning/crates.io deployment, but we should discuss how to deal with such breaking changes short/mid-term. |
@hirschenberger good news, we are planning to expand the companion PR system to this repo now, so it should be possible to move forward soonish. |
Since |
see paritytech/substrate#8619