-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
hrm, I don't understand why the android build fails |
Cargo.toml
Outdated
@@ -87,6 +88,8 @@ winapi = { version = "0.3.4", features = ["winsock2", "winuser", "shellapi"] } | |||
daemonize = "0.3" | |||
|
|||
[features] | |||
default = ["accounts"] | |||
accounts = ["ethcore-accounts", "ethcore-secretstore/accounts", "parity-rpc/accounts"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes Parity to be built with "secretstore" feature enabled by default (since default features are "accounts" and it implies "ethcore-secretstore/accounts"). I guess we need something like accounts AND secretstore = ["ethcore-secretstore/accounts"]
, but I'm not sure it could be defined within Cargo.toml. Probably replace accounts => [..., "ethcore-secretstore/accounts", ...]
with secretstore => [""ethcore-secretstore/accounts", "ethcore-accounts"]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or even better - just remove "ethcore-secretstore/accounts" from "accounts" - so that there could be --features ""
, --features "accounts"
, --features "secretstore"
and --features "secretstore accounts"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that would work, we need to enable ethcore-secretstore/accounts
if both secretstore
and accounts
features are enabled. I changed it so that we require accounts
in case we compile with secretstore
@@ -21,7 +21,7 @@ use std::sync::Arc; | |||
|
|||
use crypto::DEFAULT_MAC; | |||
use ethkey::Secret; | |||
use ethcore::account_provider::AccountProvider; | |||
use accounts::AccountProvider; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curios - are we going to leave account management under accounts
feature forever (i.e. for some long period), or it'll be totally purged from the codebase in the nearest future? In the latter case, we'll need to replace all address: H160, password: Password
in SS RPCs with something like secret: H256
or do something else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not defined yet, perhaps we are going to move some functionality to the proxy, but if we decide to remove accounts completely we need to provide some non-account-based alternatives like using secret directly. Don't know the definitive answer yet though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Co-Authored-By: tomusdrw <tomusdrw@users.noreply.github.com>
pub(crate) mod light; | ||
mod full; | ||
mod prospective_signer; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good change i.e., to break-up dispatcher
into different mods however I haven't reviewed that code. I assume it is just moved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, mostly moved, but I had to do some small changes to support the new Accounts
trait instead of using AccountProvider
directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all right, we should probably run some manual tests on the light-client
before merging because rpc integration tests are still missing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good work and LGTM.
However we need to run some manual tests on the light-client before merging.
could you sign this off @ordian @svyatonik @insipx ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SS changes are OK. The rest also seems fine, though I haven't explored it in details.
Does not compile @tomusdrw |
* master: fix: parity-clib/examples/cpp/CMakeLists.txt (#10313) CI optimizations (#10297) Increase number of requested block bodies in chain sync (#10247) Deprecate account management (#10213) Properly handle check_epoch_end_signal errors (#10015) fix(osx and windows builds): bump parity-daemonize (#10291) Add missing step for Using `systemd` service file (#10175) Call private contract methods from another private contract (read-only) (#10086) update ring to 0.14 (#10262) fix(secret-store): deprecation warning (#10301) Update to jsonrpc-derive 10.0.2, fixes aliases bug (#10300) Convert to jsonrpc-derive, use jsonrpc-* from crates.io (#10298)
ethcore-accounts
)parity-rpc
andsecret-store
(one struct) depends on it currently)engine-signer
andsecret-store
)Related: #9997
Future work: