Re-export crates used by limn as public modules

[fschutt]

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:

https://github.com/christolliday/limn/blob/ecfaabb390b9ea67a9fa0c1e3cd661d8c3880ad2/src/lib.rs#L5-L25

So if I want to make a custom widget, I have to make sure that I use the exact same version of cassowary as limn does, otherwise I get errors because the structs are not the same to the Rust compiler.

// I have to make sure to use the same version of cassowary as limn
use cassowary::strength::*;

What should be done is this (in lib.rs):

pub use cassowary;

This way, dependent crates can do this:

use limn::cassowary::strength::*;

For text-layout and limn-layout, I have to do this in my Cargo.toml:

limn        = { git = "https://github.com/christolliday/limn" }
limn-layout = { git = "https://github.com/christolliday/limn" }
text_layout = { git = "https://github.com/christolliday/limn" }

And for glutin, it's even worse, since I had to copy the lines from limns Cargo.toml, because it uses a special version:

glutin = { git = "https://github.com/christolliday/glutin", branch = "fix_windows" }

If you could re-export glutin, I could simply say use limn::glutin; instead of the above. At least for cassowary, glutin, winit and lazy_static, text_layout and limn-layout this type of re-export would be helpful.

(As a side topic): should text_layout be renamed to text-layout in the Cargo.toml - just to stay consistent?

[christolliday]

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 limn-layout, text-layout, cassowary, glutin, winit, and potentially others (webrender::api?). Not sure why you would want to re-export lazy_static though? There's no limn interface that depends on types from it.

(As a side topic): should text_layout be renamed to text-layout in the Cargo.toml - just to stay consistent?

Yep

[christolliday]

@fschutt actually I think I'll go with limn-layout and limn-text_layout, sound good?

[fschutt]

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 text-layout.

[christolliday]

if text_layout is re-exported, as it should be, as

pub extern crate limn_text_layout as text_layout;

Then, it will just be limn::text_layout, also I disagree that the folder name needs to match the crates, as long as there is a convention (limn is like a namespace)

I see it less as branding, so much as not wanting to pollute the crates.io root namespace, although that argument applies moreso to layout than text_layout (which is why layout was called limn-layout to begin with), calling it limn-text_layout just follows the same convention. If we are avoiding the limn prefix, maybe they could be cassowary_layout and text_layout. I think it's reasonable to release them as limn-layout and limn-text_layout then if they become more mature, release them without the prefix.

[fschutt]

Alright, I'll see what I can do.

[christolliday]

Done