Skip to content
This repository was archived by the owner on Nov 6, 2020. It is now read-only.

Split ethcore crate up into multiple parts #3205

Closed
rphmeier opened this issue Nov 4, 2016 · 4 comments
Closed

Split ethcore crate up into multiple parts #3205

rphmeier opened this issue Nov 4, 2016 · 4 comments
Labels
F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust. Q7-involved 💪 Can be fixed by a team of developers and probably takes some time. Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced.

Comments

@rphmeier
Copy link
Contributor

rphmeier commented Nov 4, 2016

Stuff like blockchain, client, snapshot, common types, executive/externalities can basically all be their own crates.

@rphmeier rphmeier added F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust. labels Nov 4, 2016
@nicolasochem
Copy link
Contributor

Hi @rphmeier .
I want to take a crack at this, but I am hitting issues.
The modules in ethcore use each other, so making a crate for executive/externalities/types/snapshot or most of the modules would result in circular dependencies that cargo forbids.
I have made a matrix of dependencies per module, see https://gist.github.com/nicolasochem/6a813b2cd1af3c7e9837d3b37d6c9b75

Looking at this, it is not going to be possible to simply separate the modules by moving files around. New abstractions are needed. Is my assumption correct ?

@gavofyork
Copy link
Contributor

it's mostly correct. this is a fairly big job.

@rphmeier rphmeier added the Q7-involved 💪 Can be fixed by a team of developers and probably takes some time. label Jul 10, 2017
@rphmeier
Copy link
Contributor Author

@nicolasochem That's right. As Gav says, making this change will probably require decent familiarity with the internal workings of Parity.

The types module is largely obsolete with the advent of procedural macros for serde derivation (we can strip out the unused IPC stuff for the time being until the codegen is rewritten as a macro). The way I'd start to take a crack at this would go something like this:

  • move all parts of the types modules back to where they largely belong.
  • break out an ethereum-core-types crate with Header, Block, and Transaction types
  • break out an engine crate which defines the engines (later on we'll split the implementations out). needs to abstract over something more general than ExecutedBlock since we want to have State processing higher up as well.
  • breaking out evm should be mostly painless.
  • ... and from there the remainder of ethcore would be client, blockchain, miner, and snapshot. Not sure of the best way to take those out just yet but they are definitely some of the most "entangled" pieces.

@NikVolf
Copy link
Contributor

NikVolf commented Jul 11, 2017

Btw, types in types::* are exactly collection of types that cross api boundaries between main components (sync, client, probably miner)

So it may worth splitting them into separate crate roughly as they are present now in the said module.

@5chdn 5chdn added the Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced. label Sep 4, 2017
@5chdn 5chdn closed this as completed Sep 4, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust. Q7-involved 💪 Can be fixed by a team of developers and probably takes some time. Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced.
Projects
None yet
Development

No branches or pull requests

5 participants