Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export some dependencies #289

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@stevenroose
Copy link
Collaborator

commented Jul 6, 2019

This export bitcoin_hashes as bitcoin::hashes and secp256k1 as bitcoin::secp256k1.

This would mean that users of rust-bitcoin, (1) don't have to manually import those dependencies anymore and more importantly (2) can avoid certain dependency imcompatibility issues if some other module they use is using another version of bitcoin_hashes or secp256k1.

Solves #288.

stevenroose added some commits Jul 6, 2019

@apoelstra

This comment has been minimized.

Copy link
Member

commented Jul 6, 2019

Users will have trouble with multiple versions of secp256k1 regardless, until we figure out how to version the C symbols, but concept ACK.

Can you also export bitcoin_bech32? Or are we planning to drop that dependency in favor of an Elements-like inline solution?

@stevenroose

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 6, 2019

Expecting to drop that with #255. But I can reexport it here for correctness and drop it in #255. Actually let me check #255, Sebastian told me bech32 should be good to go to finish that PR.

@dongcarl

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

Concept ACK, after a brief glance there doesn't seem to be a way to transitively use dependencies in rust, so I suspect this will be useful.

@thomaseizinger

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

Since I originally opened #288, I think this might be useful:

There is one pitfall that might be worth considering. If we re-export a whole crate, that crate's public API becomes part of rust-bitcoin's public API and hence any breaking changes to that are automatically breaking changes to rust-bitcoin.

A different approach, that doesn't eliminate all of those breaking changes but some, would be to selectively re-export the types we want. For example (to mimic the "old" API):

extern crate bitcoin_hashes;

pub mod hashes {
   pub use bitcoin_hashes::hash160::Hash as Hash160;
}

Obviously, if there are now breaking changes to Hash160, they are breaking changes for rust-bitcoin as-well.
In a nut-shell, I think the only thing you can avoid here is if bitcoin_hashes moves stuff around, those breaking changes could be avoided to bubble up to consumers of rust-bitcoin.

@apoelstra

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

@thomaseizinger Breaking changes to bitcoin_hashes are breaking changes to rust-bitcoin anyway, because e.g. bitcoin_hashes::sha256d::Hash is exposed as part of bitcoin::OutPoint.

@apoelstra

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

In principle (by using the dtolnay semver trick) there could be a major version bump to bitcoin_hashes that wouldn't affect rust-bitcoin users, but in practice the semver trick has not been available to us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.