Skip to content

Export some dependencies #289

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

Merged
merged 2 commits into from
Aug 16, 2019
Merged

Conversation

stevenroose
Copy link
Collaborator

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.

@apoelstra
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Member

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.

apoelstra
apoelstra previously approved these changes Jul 11, 2019
@stevenroose
Copy link
Collaborator Author

rebased

Copy link
Member

@dongcarl dongcarl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You missed a place :-)

diff --git a/src/util/bip158.rs b/src/util/bip158.rs
index 30aee13..ac517dd 100644
--- a/src/util/bip158.rs
+++ b/src/util/bip158.rs
@@ -50,7 +50,7 @@ use std::error;
 use std::fmt::{Display, Formatter};
 use std::io::Cursor;

-use bitcoin_hashes::{Hash, sha256d, siphash24};
+use hashes::{Hash, sha256d, siphash24};
 use byteorder::{ByteOrder, LittleEndian};

 use blockdata::block::Block;

Otherwise, good change overall.

To other reviewers: I was concerned that users of our API would be confused that there existed a hashes crate we were using, but upon cargo doc --open I can see that pub extern crate bitcoin_hashes as hashes; is right there on the front page. So, all good!

@apoelstra apoelstra added this to the 0.19 milestone Jul 27, 2019
@stevenroose
Copy link
Collaborator Author

To other reviewers: I was concerned that users of our API would be confused that there existed a hashes crate we were using, but upon cargo doc --open I can see that pub extern crate bitcoin_hashes as hashes; is right there on the front page. So, all good!

True. But I envision users that only want bitcoin_hashes without bitcoin will be library devs in the rust-bitcoin community anyway, so they will know about the crate. I think most other users will just only depend on bitcoin and use bitcoin::hashes:: instead.

@apoelstra
Copy link
Member

travis failed because of #300 which appears to be an unrelated bug. You can just kick it and it should be ok.

@dongcarl
Copy link
Member

dongcarl commented Aug 2, 2019

Kicked

apoelstra
apoelstra previously approved these changes Aug 2, 2019
@apoelstra
Copy link
Member

Needs rebase

@stevenroose
Copy link
Collaborator Author

Rebased

@codecov-io
Copy link

codecov-io commented Aug 15, 2019

Codecov Report

Merging #289 into master will not change coverage.
The diff coverage is 80%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #289   +/-   ##
=======================================
  Coverage   81.85%   81.85%           
=======================================
  Files          38       38           
  Lines        6951     6951           
=======================================
  Hits         5690     5690           
  Misses       1261     1261
Impacted Files Coverage Δ
src/network/message_filter.rs 0% <ø> (ø) ⬆️
src/util/base58.rs 80.68% <ø> (ø) ⬆️
src/util/contracthash.rs 78.5% <ø> (ø) ⬆️
src/util/misc.rs 96.77% <ø> (ø) ⬆️
src/util/address.rs 86.12% <ø> (ø) ⬆️
src/util/bip158.rs 93.09% <ø> (ø) ⬆️
src/lib.rs 100% <ø> (ø) ⬆️
src/util/bip143.rs 100% <ø> (ø) ⬆️
src/util/psbt/mod.rs 86.06% <ø> (ø) ⬆️
src/network/message_blockdata.rs 36.36% <ø> (ø) ⬆️
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5f4de0f...c011727. Read the comment docs.

apoelstra
apoelstra previously approved these changes Aug 15, 2019
Copy link
Member

@dongcarl dongcarl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the two instances of bitcoin_hashes here:

https://github.com/rust-bitcoin/rust-bitcoin/pull/289/files#diff-ca925ea633ee82c8b9dfd44534146107R575-R578

I will approve and merge after.

@stevenroose
Copy link
Collaborator Author

Please fix the two instances of bitcoin_hashes here:

https://github.com/rust-bitcoin/rust-bitcoin/pull/289/files#diff-ca925ea633ee82c8b9dfd44534146107R575-R578

I will approve and merge after.

Hmm, I left them on purpose tbh. But I can fix them. I'll rename them to bitcoin::hashes then, is that ok? Hashes itself doesn't mean anything outside this crate.

@stevenroose
Copy link
Collaborator Author

stevenroose commented Aug 16, 2019 via email

@stevenroose
Copy link
Collaborator Author

In retrospect, it's an internal macro. I changed it to just hashes.

Copy link
Member

@dongcarl dongcarl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested-ACK c011727

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants