-
Notifications
You must be signed in to change notification settings - Fork 19
Re-export crates used by limn as public modules #23
Comments
Yeah this makes sense to me, I thought maybe it wasn't a good idea before, but can't think of a good reason not to now, especially for
Yep |
@fschutt actually I think I'll go with |
Well, for the final user, it would look like this: #[macro_use]
extern crate limn;
use limn::text_layout;
use limn::limn_layout; So then it would be: use limn::limn_text_layout; Maybe a bit too much branding. I thought that the modules should be named after the folders they are in, to not confuse anyone. So I'd stick with just |
if text_layout is re-exported, as it should be, as
Then, it will just be I see it less as branding, so much as not wanting to pollute the crates.io root namespace, although that argument applies moreso to |
Alright, I'll see what I can do. |
Done |
Here's the thing: I want to be sure that I use the same version of the crates used by limn itself, in order to not get a version mismatch. Currently, the situation looks like this:
limn/src/lib.rs
Lines 5 to 25 in ecfaabb
So if I want to make a custom widget, I have to make sure that I use the exact same version of
cassowary
aslimn
does, otherwise I get errors because the structs are not the same to the Rust compiler.What should be done is this (in
lib.rs
):This way, dependent crates can do this:
For
text-layout
andlimn-layout
, I have to do this in my Cargo.toml:And for
glutin
, it's even worse, since I had to copy the lines fromlimn
s Cargo.toml, because it uses a special version:If you could re-export
glutin
, I could simply sayuse limn::glutin;
instead of the above. At least forcassowary
,glutin
,winit
andlazy_static
,text_layout
andlimn-layout
this type of re-export would be helpful.(As a side topic): should
text_layout
be renamed totext-layout
in theCargo.toml
- just to stay consistent?The text was updated successfully, but these errors were encountered: