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

Split crate into multihash, multihash-codetable and multihash-derive #266

Closed
Tracked by #267
thomaseizinger opened this issue Jan 20, 2023 · 5 comments
Closed
Tracked by #267

Comments

@thomaseizinger
Copy link
Contributor

As discussed in #259.

This issue tracks the splitting up into smaller crates for the purpose of a more stable API.

@thomaseizinger
Copy link
Contributor Author

I am tempted to introduce an additional crate: multihash-derive-impl. The reason is as follows.

There are several symbols that would reside in multihash that are only needed for the custom derive:

  • MultihashDigest
  • Hasher
  • Error::UnsupportedCode

We could move all of those to multihash-derive, move the actual derive code to multihash-derive-impl and thus refer to these types via multihash-derive. multihash-derive would then also depend on multihash (and re-export) the struct.

This would reduce in an even smaller API surface of multihash. Thoughts @vmx?

@vmx
Copy link
Member

vmx commented Mar 21, 2023

Would it be an issue to have multihash-derive-impl and miltihash-derive in a single crate? I'd expect that most people would use them together anyway. Though I might be missing something.

@thomaseizinger
Copy link
Contributor Author

Would it be an issue to have multihash-derive-impl and miltihash-derive in a single crate? I'd expect that most people would use them together anyway. Though I might be missing something.

The problem is that a proc-macro cannot declare regular Rust symbols like traits or structs because proc-macros are compiled for the host machine and the actual crates for the specified target.

Thus, the types like MultihashDigest, Hasher and UnsupportedCode cannot live next to the proc macro. To make things easier to use though, the macro from the -impl crate is typically re-exported, meaning users still just depend on multihash-derive.

I've implemented this here already: #272

As you can see, someone defining their own codetable would only depend on multihash-derive and get everything they need. Someone that just needs the data structure Multihash would depend on multihash.

@vmx
Copy link
Member

vmx commented Mar 21, 2023

Thanks for the explanation, that makes sense. Having this documented should make it easy enough to follow as the multihash-derive-impl will really be more or less an implementation detail of multihash-derive.

@thomaseizinger
Copy link
Contributor Author

Done as part of #267.

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

No branches or pull requests

2 participants