Why not publish the 17.0 version of ethabi-derive and ethabi-contract
KaoImin opened this issue · comments
This wasn't a conscious choice. However now in hindsight I would still say that all the development in this repository only concerned the main ethabi library. The other crates saw no changes so I am not sure if they need new versions.
Do you think they should have new versions?
If you have the following in your Cargo.toml
ethabi = "17.0" ethabi-contract = "16.0" ethabi-derive = "16.0"
ethabi-derive = "16.0" will also pull in ethabi = "16.0" which in turn pulls in two different versions of ethereum-types.
This is a good point, and I think we should publish v17 ethabi-* crates. Would you mind making a PR with version updates? We can publish once its merged.
I feel like I commented this in another issue already but we don't have the ability to publish the other crates on crates.io anyway.
Quickly glancing over the code in the master branch, it looks like the versions are already fine.
But why don't you have the ability to publish the other crates?
We don't have crates.io ownership over the other crates. This project was originally developed by Parity developers while some people from rust-ethereum give it life support now. When we moved ownership I think we simply forgot the other two crates and this is the first issue where anyone noticed.
Ok, I understand.
Do you have contacts at Parity, who you could ask to add you to the other projects at crates.io?
(Sorry for being too terse before.) We can try. The first ownership change was difficult because the person owning the crates on crates.io for Parity no longer works there (?) and has been hard to reach. I'm not sure if investing time into this is worth it because of the few people that use the non main ethabi crate and because those crates haven't received any updates except for the ethabi version bump.
I see. The problem I have at the moment is, that I wanted to update a dependency in a completely different part of our software, and it led to an incompatibility here. Replacing ethabi-contract and ethabi-derive with something else could be quite an effort for little reward.
I even tried to specify the git repo directly instead of crates.io in my Cargo.toml, but that also doesn't work because another crate has a sub dependency to the ethabi from crates.io.
I even tried to specify the git repo directly instead of crates.io in my Cargo.toml, but that also doesn't work because another crate has a sub dependency to the ethabi from crates.io.
You can try a [patch] instead... although you would have to keep everything on 16.0 (so your git revision should change ethabi's Cargo.toml to v16 instead of bumping ethabi-* to v17).
We can try.
I think we can reach out. But as @vkgnosis said, I wouldn't hold your breath.
Cool, using [patch] I could solve it for now. I never used that before.
It would still be better to publish them however.