Restore `no_std` compatibility for JSON serialization impls
Closed this issue · 8 comments
FYI: Reached out to the ComposableFi, they mentioned that they plan to upgrade their ibc-proto-rs fork from the upstream, but not earlier than in a month or two
Just noticed upon upgrading ibc-proto-rs to v0.31.0 in ibc-rs (this PR), the CI can’t pass no-std-check in which we make the serde feature on to check no-std compatibility for the Substrate users. (The ics23/serde works for std environments)
Sounds like we either should (1) upstream no_std compliance for pbjson or alternatively (2) define some domain types representing ics23 protos so can derive no-std serde on them.
Also, @DaviRain-Su to check with you: are you dependent on any of the derived serde within the ic23_commitment of ibc-rs (e.g. here) at the moment?
Also, @DaviRain-Su to check with you: are you dependent on any of the derived serde within the ic23_commitment of ibc-rs (e.g. here) at the moment?
I have not any dependent for this.
Glad to hear! Then let's close this if no one objects.
Should the need for pbjson support on no-std arise in the future we may look into adding that (I actually have a WIP branch doing just that but more work is needed and I have more pressing things to take care of at the moment).
Given the need brought up in cosmos/ibc-rs#741, this issue is reopened.
Hm, actually all was working until very specific commit recently. May be 3 weeks ago.
In Composable there are 2 forks, one is 0.15 version (super old, on of reason was no_std issue i recall), and other one on last version before serde in no_std was broken (so we again no_std issue).
We are trying to be first chain to be Cosmos like chain (CW and IBC) not written in Go, but that is really hard. Issue is that when CW lib or IBC-rs break no_std, it would go deep several libs down the way, and unrealistically to drive fixes of no_std in so many libs.
No sure how other no_stds handle that. In current case no_std broken in some dep which depens on some generator.
We are trying to be first chain to be Cosmos like chain (CW and IBC) not written in Go, but that is really hard. Issue is that when CW lib or IBC-rs break no_std, it would go deep several libs down the way, and unrealistically to drive fixes of no_std in so many libs.
Sorry hearing that you are experiencing such trouble.
Hopefully, #118 should fix the issue. Let us know if any other adjustments needed regarding no_std