-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Open
Copy link
Labels
fyi: gatekeepersFor information - Catalyst App Backend, System Development & Integration TeamFor information - Catalyst App Backend, System Development & Integration Teamfyi: hermeticsFor information - Hermes Backend, System Development & Integration TeamFor information - Hermes Backend, System Development & Integration TeamhermesTask could/should be picked up as work on Hermes.Task could/should be picked up as work on Hermes.p: highThe issue or pull request is high priority and needs to be addressed soonThe issue or pull request is high priority and needs to be addressed soonrefactorCode refactoring taskCode refactoring taskrr: architectureRequired review - Architecture team must approve before mergeRequired review - Architecture team must approve before mergerr: gatekeepersRequired review by gatekeepers teamRequired review by gatekeepers teamsquad: hermeticsHermes Backend, System Development & Integration TeamHermes Backend, System Development & Integration Team
Description
Summary
Fork Pallas and remove a dependency on tokio for types which are not performing IO.
Description
Pallas defines types and constants (such as Point) in the pallas-network
crate.
This creates a direct and impossible to break dependency on tokio, which then makes the code unusable in WASM.
The fix here is to:
- Update our fork in https://github.com/input-output-hk/catalyst-pallas with latest upstream pallas code, (if it is not already).
- Create a feat/pallas-network-types branch
- In that branch move the Point type, and other constants from
pallas-network/src/miniprotocols/common.rs
into thepalls-primitives
crate. - Recommended approach is to make a
point.rs
which has the point type, and anetwork-constants.rs
which has all the constants. - Alias the Point in the original
pallas-network
crate to point to the moved Point in pallas-primitives, and use the constants from the newnetwork-constants.rs
file to set the original constant values. (This should mean that there are no breaking changes because using the type frompallas-network
can still work, but the true source is inpallas-primitives
. However any use of Point or these constants withinpallas
should be changed to use the new definitions inpallas-primitives
so that there is no unnecessary dependency onpallas-network
. - Ensure that the aliases are properly marked with
#[deprecated]
as they should not be the preferred place to use the type. Make sure to define a propernote
in the deprecation advising where the type or constant should now be imported from. - Update our libraries to use our fork, and this branch, and use Point from the new location.
- Ensure that the change is all thats required to prevent pallas-network needing to be used to compile our code to WASM.
- If it is not, keep extracting types and constants as described above until it is clean.
- Once we are sure everything builds OK, push a PR back to tx-pipe/palls upstream repo with this change.Note, this partially satisfies: De-dupe duplicated primitives structs from pallas-network (by switching to generics) txpipe/pallas#620
Also See: https://github.com/txpipe/pallas/blob/6c1e0868e1d128733cf6bdb1638edb5915a00ab7/pallas-hardano/src/storage/immutable/mod.rs#L15 This comment should be cleaned up when the type is moved.
Metadata
Metadata
Assignees
Labels
fyi: gatekeepersFor information - Catalyst App Backend, System Development & Integration TeamFor information - Catalyst App Backend, System Development & Integration Teamfyi: hermeticsFor information - Hermes Backend, System Development & Integration TeamFor information - Hermes Backend, System Development & Integration TeamhermesTask could/should be picked up as work on Hermes.Task could/should be picked up as work on Hermes.p: highThe issue or pull request is high priority and needs to be addressed soonThe issue or pull request is high priority and needs to be addressed soonrefactorCode refactoring taskCode refactoring taskrr: architectureRequired review - Architecture team must approve before mergeRequired review - Architecture team must approve before mergerr: gatekeepersRequired review by gatekeepers teamRequired review by gatekeepers teamsquad: hermeticsHermes Backend, System Development & Integration TeamHermes Backend, System Development & Integration Team
Type
Projects
Status
New