Get bigint on crates.io

[rphmeier]

As ethcore-bigint

[tomusdrw]

What's the benefit if the code is in a single repo anyway?

[rphmeier]

It makes it easier to observe changes -- personally I hate to review a PR which is just a version bump + Cargo.lock hash change, because it almost always means that this "insubstantial" PR is just a mask for one which hasn't been properly reviewed.

[coveralls]

Coverage decreased (-0.1%) to 84.671% when pulling 14c0c24 on bigint_crates into 341e064 on master.

[tomusdrw]

Oh, yeah - I agree. My point is why do we change references to ethcore-bigint from ethcore-bigint = {path = "../util/bigint"} to ethcore-bigint = "<crates-version>"

Right now someone will make a change in util/bigint and it will not be used when compiling parity so we won't be even able to figure out that something is broken.

[arkpar]

Agree with @tomusdrw. Local references should use relative path.

[rphmeier]

my reasoning behind using crates.io version was to ensure that changes actually get propagated to crates.io. if not, the crate might stagnate more than necessary.

but i suppose the relative path is probably better

[rphmeier]

Another reason, which only just occurred to me now, is that you can't have local dependencies for published crates.

As we may want to publish an rlp and trie crate, they will need to reference concrete crates.io versions. I think cargo workspaces will smooth this over a bit.

[rphmeier]

Travis failure seems spurious, it's very strange. It can't fetch the source for https://github.com/ethcore/hyper for some reason.

[coveralls]

Coverage increased (+0.3%) to 85.268% when pulling 9dbc49b on bigint_crates into 2ba4968 on master.