Feature/enable tests

[stephenctw]

#42, #39
This bump the parity crates to the latest stable version (2.7.2). Adapted API changes, fixed tests and example, used Solidity version 5.1.17^, updated README.

[dvdplm]

Thank you for the contribution!

Do you think it would be possible to fetch dependencies from crates? We just upgraded openethereum to the latest crates so it should be possible to use ethabi v12 and ethereum-types v0.9. There's that pesky dependency on common-types that might cause issues, so I think this code as-is will already be broken. :/

[stephenctw]

Sure, do you have an example I can take a look at how to achieve this? I not an expert of Rust nor familiar with the OpenEthereum code base.

[dvdplm]

So this is where it becomes a bit nasty. The stable branch is probably a good idea but maybe we should try tying this to a specific release branch/tag? cc @denisgranha do we have a branch for the upcoming 3.0 release?
Publishing the ethcore crate would snowball into a major undertaking I think. Do you think we can refactor things to not use it at all? Looks like we're using it for an error type and the EvmTestClient only. If we could untangle this from ethcore it would be much easier to maintain. Maybe we could publish trace and spec crates, but I'm not sure.

[denisgranha]

hi guys, so far the branch for the upcoming release will be based from master, is not there yet until last changes are implemented.

I guess if you want to try things out that should be in another branch? or there is something about rust crates that I’m missing? so far stable branch is not being used as far as I know @vorot93

[dvdplm]

The problem here is that we have here a project that is external to openethereum but uses code from it, fetching individual subcrates. It will break a lot. We can solve/improve on this in several ways, all of which have problems:

1. do nothing; dependent projects use git dependencies and break often and we just deal with that
2. pin dependencies to a single branch or revision, much like @606simps did here
3. publish the crates
4. bring this project or others into the openethereum repo

I think the second option is perhaps the least worst. And maybe for the time being we should pin it to a specific "known-good" revision, i.e. current master.

wdyt?

[denisgranha]

I see.

Yeah, option 2 might be the better here. Why use a branch though? wouldn't be better a specific tag? I can see in the docs https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories that tag versioning is possible, wouldn't not work well in this case?

[stephenctw]

Yes tag works fine. I tried tag "v3.0.0-alpha.1", it doesn't compile. Which tag should I use?

[denisgranha]

mmm it should compile, we have a CI for it and some releases https://github.com/openethereum/openethereum/actions/runs/68094801

What error are you getting? @606simps

[stephenctw]

@dvdplm suggests to use ethabi version "12.0". I am getting a version conflict error.

    Updating git repository `https://github.com/openethereum/openethereum.git`
    Updating crates.io index
error: failed to select a version for `cc`.
    ... required by package `secp256k1-sys v0.1.1`
    ... which is depended on by `secp256k1 v0.17.2`
    ... which is depended on by `parity-crypto v0.5.0`
    ... which is depended on by `authority-round v0.1.0 (https://github.com/openethereum/openethereum.git?tag=v3.0.0-alpha.1#d4b5720d)`
    ... which is depended on by `spec v0.1.0 (https://github.com/openethereum/openethereum.git?tag=v3.0.0-alpha.1#d4b5720d)`
    ... which is depended on by `ethcore v1.12.0 (https://github.com/openethereum/openethereum.git?tag=v3.0.0-alpha.1#d4b5720d)`
    ... which is depended on by `solaris v0.1.0 (/home/stephen/git/Cartesi/sol-rs/solaris)`
    ... which is depended on by `solaris-example v0.1.0 (/home/stephen/git/Cartesi/sol-rs/example)`
versions that meet the requirements `>= 1.0.28, <= 1.0.41` are: 1.0.41, 1.0.40, 1.0.39, 1.0.38, 1.0.37, 1.0.36, 1.0.35, 1.0.34, 1.0.33, 1.0.32, 1.0.31, 1.0.30, 1.0.29, 1.0.28

all possible versions conflict with previously selected packages.

  previously selected package `cc v1.0.50`
    ... which is depended on by `backtrace-sys v0.1.35`
    ... which is depended on by `backtrace v0.3.46`
    ... which is depended on by `error-chain v0.12.2`
    ... which is depended on by `ethabi v9.0.1`
    ... which is depended on by `authority-round v0.1.0 (https://github.com/openethereum/openethereum.git?tag=v3.0.0-alpha.1#d4b5720d)`
    ... which is depended on by `spec v0.1.0 (https://github.com/openethereum/openethereum.git?tag=v3.0.0-alpha.1#d4b5720d)`
    ... which is depended on by `ethcore v1.12.0 (https://github.com/openethereum/openethereum.git?tag=v3.0.0-alpha.1#d4b5720d)`
    ... which is depended on by `solaris v0.1.0 (/home/stephen/git/Cartesi/sol-rs/solaris)`
    ... which is depended on by `solaris-example v0.1.0 (/home/stephen/git/Cartesi/sol-rs/example)`

failed to select a version for `cc` which could resolve this conflict

[stephenctw]

[dependencies]
ethabi = "12.0.0"
ethcore = { git = "https://github.com/openethereum/openethereum.git", tag = "v3.0.0-alpha.1", features = ["test-helpers"]}
common-types = { git = "https://github.com/openethereum/openethereum.git", tag = "v3.0.0-alpha.1" }
trace = { git = "https://github.com/openethereum/openethereum.git", tag = "v3.0.0-alpha.1" }
spec = { git = "https://github.com/openethereum/openethereum.git", tag = "v3.0.0-alpha.1" }
parity-bytes = "0.1"
ethereum-types = "0.9.0"
evm = { git = "https://github.com/openethereum/openethereum.git", tag = "v3.0.0-alpha.1" }
lazy_static = "0.2"
vm = { git = "https://github.com/openethereum/openethereum.git", tag = "v3.0.0-alpha.1" }
error-chain = "0.12.0"

[dvdplm]

previously selected package cc v1.0.50

So this is something that pops up sometimes. During dependency resolution some crate picked cc at 1.0.50 which causes secp256k1 to fail. We've pinged upstream about their strict requirement on cc but for the time being your best bet is to manually edit Cargo.lock: find the dependency that picks cc 1.0.50 and change it to 1.0.41 instead.

[stephenctw]

v3.0.0-alpha.1 has other dependencies conflict. What other tag should I use?
https://github.com/openethereum/openethereum/blob/d4b5720df0572a3f79783b1c9e55c765e20e2475/ethcore/Cargo.toml#L26
https://github.com/openethereum/openethereum/blob/d4b5720df0572a3f79783b1c9e55c765e20e2475/ethcore/machine/Cargo.toml#L31

[stephenctw]

Thank you for the contribution!

Do you think it would be possible to fetch dependencies from crates? We just upgraded openethereum to the latest crates so it should be possible to use ethabi v12 and ethereum-types v0.9. There's that pesky dependency on common-types that might cause issues, so I think this code as-is will already be broken. :/

Yeah so on the master branch, the common-types fails to load the source because one submodule can't find the id(06acfb48aee71ecb57a9ca991cf0f57b630e3469)

    Updating git repository `https://github.com/openethereum/openethereum.git`
error: failed to load source for a dependency on `common-types`

Caused by:
  Unable to update https://github.com/openethereum/openethereum.git

Caused by:
  failed to update submodule `ethcore/res/ethereum/tests`

Caused by:
  object not found - no match for id (06acfb48aee71ecb57a9ca991cf0f57b630e3469); class=Odb (9); code=NotFound (-3)

It looks like a commit from the ethereum repo no longer exists in the tree. Do you have a fix for it?

[dvdplm]

It looks like a commit from the ethereum repo no longer exists in the tree. Do you have a fix for it?

This is caused by a submodule not being synced to what's in the git repo (in this case the one in ethcore/res/ethereum/tests). Try git submodule update perhaps?

[stephenctw]

It looks like a commit from the ethereum repo no longer exists in the tree. Do you have a fix for it?

This is caused by a submodule not being synced to what's in the git repo (in this case the one in ethcore/res/ethereum/tests). Try git submodule update perhaps?

But I am importing the crate directly from git repository (https://github.com/openethereum/openethereum.git). Not using the crate with source code, how do I update the submodule in this case?

EDIT: NVM, found fix here. Now I can build with the master branch, still fails with the tag v3.0.0-alpha.1 though

[dvdplm]

EDIT: NVM, found fix here. Now I can build with the master branch, still fails with the tag v3.0.0-alpha.1 though

Good, I forgot we had this come up recently. I'm fine merging this with a dependency on master but I'd add a todo to switch to the release tag as soon as possible. I suspect the tag is simply outdated.

[dvdplm]

Hmm, @denisgranha it looks like the CI is broken for this repo. Can you take a look please?

[denisgranha]

right we need to change the CI, will take care of it

[denisgranha]

hi @606simps the Travis CI was enabled again in the current org https://travis-ci.com/github/openethereum/sol-rs

It's failing on master not sure if it will on yours too. If you pull from master, you should get the CI running

[stephenctw]

hi @606simps the Travis CI was enabled again in the current org https://travis-ci.com/github/openethereum/sol-rs

It's failing on master not sure if it will on yours too. If you pull from master, you should get the CI running

I rebased on top of the master branch but there's this issue. How can we apply the fix in the CI?