Skip to content
This repository has been archived by the owner on Jun 26, 2021. It is now read-only.

Re-export crates used by limn as public modules #23

Closed
fschutt opened this issue Oct 16, 2017 · 6 comments
Closed

Re-export crates used by limn as public modules #23

fschutt opened this issue Oct 16, 2017 · 6 comments

Comments

@fschutt
Copy link
Contributor

fschutt commented Oct 16, 2017

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

extern crate text_layout;
#[macro_use]
extern crate limn_layout;
extern crate cassowary;
extern crate rusttype;
extern crate glutin;
#[macro_use]
extern crate lazy_static;
extern crate linked_hash_map;
extern crate stable_bst;
#[macro_use]
extern crate maplit;
#[macro_use]
extern crate downcast_rs;
extern crate euclid;
#[macro_use]
extern crate log;
extern crate webrender;
extern crate gleam;
extern crate app_units;
extern crate image;

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

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

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

@fschutt
Copy link
Contributor Author

fschutt commented Oct 19, 2017

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

christolliday commented Oct 20, 2017

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

fschutt commented Oct 20, 2017

Alright, I'll see what I can do.

@christolliday
Copy link
Owner

Done

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

No branches or pull requests

2 participants