Please re-export bson lib.
thedodd opened this issue · comments
It would be really awesome if this create would pub use bson; from the root of the library. Here is some reasoning as to why:
- every time this library releases a new version (even patch versions) where the
bsondependency changes, everything breaks. Users of this library must (currently) depend on the BSON crate (because you need to in order to use the mongo crate).- the best you can do to mitigate this issue is to require the closest
minorversion ofbsonwhich matches this crate's dep. When the bson dep is updated from, say,0.10->0.12, this doesn't help. - having the dep as
bson = "*"does not help either, because if bson0.13is released, and this create still requires0.12, then things still break.
- the best you can do to mitigate this issue is to require the closest
- BSON is not used that often outside of mongodb context. So ... why not just re-export it from this lib? Users could still directly depend on it if they ever needed it outside of mongodb context, of course, even if it is re-exported from this crate.
This issue presents as follows:
error[E0308]: mismatched types
--> myfile.rs:666:666
|
666 | ... blah blah some code ...
|
= note: expected type `bson::ordered::OrderedDocument` (struct `bson::ordered::OrderedDocument`)
found type `bson::ordered::OrderedDocument` (struct `bson::ordered::OrderedDocument`)
note: Perhaps two different versions of crate `bson` are being used?
Error message is spot on, and very helpful. But there is still a compilation error.
Once re-exported by this crate, users would bring it into scope via use mongodb::bson; and would not even need to declare it as an additional dependency.
As always, thanks for the great work on this lib. I'm stoked to see it continue to evolve. Hoping to help out a bit more in the future myself. Especially to get some async i/o support in place.
I think this makes a lot of sense; there's no reason to force users to manually keep the version they import directly in sync with the version this crate uses.
@kyeah, are you okay with this change? If so, I'll make a PR doing it
Awesome! 🙌 You guys rock! Thanks for the quick response.
Upon further inspection, this might not be possible right now; while it's possible to reexport all of the items in the bson crate, it isn't possible to reexport the macros in the crate. According to this issue, the only way that ever existed to do this was the nightly-only macro_reexport, which was recently removed. pub use is described as being the eventual replacement for this; I believe as part of macros 2.0, macros are going to be first-class items that can be imported and exported like anything else, which would solve this issue.
It's possible that there might be a clever solution to define a new macro that "wraps" the old one, but I'm not sure what it would look like. The issue of macros not being items complicates things here too; since there's no module path for them, we couldn't define our own macro called doc! and call the old one in the same namespace.
Given that the doc! macro is basically a necessity for using the crate, I don't think it would be worth it to do this if we couldn't reexport it.
@saghm we may be able to with pub use. Some additional discussion here: https://users.rust-lang.org/t/solved-is-it-possible-to-reexport-a-proc-macro/16864/7
That link is entitled “proc-macro” but mentions macro_rules macros. Worth some experimentation.
Another item I came by: https://stackoverflow.com/questions/50037091/how-to-use-macros-from-re-exported-crates
Looks like Rust 1.30 (which was just released) adds the feature I mentioned, which obviates any need for a workaround: https://blog.rust-lang.org/2018/10/25/Rust-1.30.0.html
On a related note: can you guys in the meantime release a 0.3.11 version of this crate? That would be the one that already depends on bson 0.13, which fixes a serialization bug (which I've been blocked on for some time now).