move chain_config to separate crate #635
Conversation
leviathanbeak
changed the title
|
Would it be good to have Relayer and p2p config cli commands moved into a config crate as well. That way all the configuration and parameters to run the network could be in a single place. I'm just curious if this is something we'd want to add into this new crate (which may then require a more general rename). But I have no problems on the impl, LGTM overall and can approve if there is a reason for against a central config crate with those additional options |
|
@ControlCplusControlV IMO the cli config commands should stay with the CLI app (unless whole CLI app gets moved). These config constructs that I've moved out are mostly that someone (ie SDK) can import them without importing whole of |
…beak/relocate_chain_config
|
Missing README.md for new package |
|
@Voxelot please re-review 🎉 |
|
reserved the name on crates.io: https://crates.io/crates/fuel-chain-config |
|
Maybe we should organize this new crate a bit more and move the different structs/traits into their own submodule files? I'm finding it easy to get lost in this large lib.rs. |
|
@Voxelot good point, I'll do it |
…Labs/fuel-core into leviathanbeak/relocate_chain_config
|
I've moved config structs into separate files: |
…beak/relocate_chain_config
fuel-tests/Cargo.toml
Outdated
| @@ -19,6 +19,7 @@ harness = true | |||
| [dependencies] | |||
| async-std = "1.12" | |||
| chrono = { version = "0.4", features = ["serde"] } | |||
| fuel-chain-config = { path = "../fuel-chain-config", version = "0.1.0" } | |||
There was a problem hiding this comment.
use re-exported config from fuel-core instead of making a new dep here.
fuel-chain-config/Cargo.toml
Outdated
| @@ -0,0 +1,27 @@ | |||
| [package] | |||
| name = "fuel-chain-config" | |||
| version = "0.1.0" | |||
There was a problem hiding this comment.
version must match the other crates in lockstep to pass publish tag verification during the publish ci job
| version = "0.1.0" | |
| version = "0.10.1" |
closes #603
Mostly copy/pasta apart from one important change, since
ChainConfigwas tightly coupled withDatabase(Db was passed during initialization of ChainConfig), I have created aChainConfigDbtrait which I passed instead. And on thefuel-core/Databaseside I have implemented that trait so that it is compatible forChainConfiginitialization.By "implemented" I mean the methods were already previously implemented so I just referenced existing methods in trait implementation.