Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate type usage of sp_runtime and sp_core #553

Closed
haerdib opened this issue Apr 26, 2023 · 3 comments
Closed

Investigate type usage of sp_runtime and sp_core #553

haerdib opened this issue Apr 26, 2023 · 3 comments
Assignees
Labels
F7-enhancement Enhances an already existing functionality Q5-involved Will take some time to fix this

Comments

@haerdib
Copy link
Contributor

haerdib commented Apr 26, 2023

As written here: #541 (comment)

subxt inserted this in paritytech/subxt@b316301#diff-57540144ef1381f66537718f59e717110353e5408cdf539b67f7a1ff9cdd0d10 to make sp_core and sp_runtime dependencies optional. See paritytech/subxt#760.
The Header trait has also been inserted for this purpose.
Removing these would certainly simplify our configurations and code. If our goal is to have an easy to use configuration, we should do it. But I like subxt idea of "Reducing the need to keep up to date with Substrate packlage versions". See PR paritytech/subxt#760

One should decide if it makes sense to completely remove sp_runtiem and sp_core dependency. But also the implications of it. See #391

@haerdib haerdib added Q5-involved Will take some time to fix this F7-enhancement Enhances an already existing functionality labels Apr 26, 2023
@haerdib haerdib self-assigned this Jun 5, 2023
@haerdib
Copy link
Contributor Author

haerdib commented Jun 7, 2023

We decided to remove the duplicate types as much as possible but keep the deps instead.

@haerdib
Copy link
Contributor Author

haerdib commented Jun 7, 2023

Pro for keeping it:

  • No need for type updates in our own code base in case substrate updates the types
  • less complicated for users: one type only
  • More flexibility for users in types (full type information always available)

@haerdib
Copy link
Contributor Author

haerdib commented Jun 7, 2023

Since we came to a conclusion, I'm closing this issue. The types will be removed in #391

@haerdib haerdib closed this as completed Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F7-enhancement Enhances an already existing functionality Q5-involved Will take some time to fix this
Projects
None yet
Development

No branches or pull requests

1 participant