Hmmmm, do you mean that you don't want to put all your `extern crate` statements in the root of your library? If you do that, you don't have to have the `self` when you use items from the crate within your modules. I've never wanted to put my `extern crate` statements within a module rather than the library crate root; can you elaborate on why you want to do that?

Hm, I'm still confused about what you're trying to do :-/ If you're trying to use something from tokio_core in your own crate, in neither place will `use self` do that, like you had in your first example... it would be `use tokio_core::foo::Bar`... and the `self` was the only difference between the binary and library, so I'm not sure what the paper cut is exactly.

Basically I start hacking on a project, then when finally something is working, I want to split it into a separate "something". Coming from the C++ world, I'd create a new cpp/h couple, maybe in its own subdir. I understand that the equivalent in Rust is creating a module.

I made a simple example with just two files: (In the meanwhile I realized that my first example was wrong :) https://github.com/lucaotta/rust_modules

Let's say that after my refactor, I've "moved" the crate import into the module since "logically" it belongs there. In this case the compilation fails if I don't use self::. But previously it was working in main.rs! And I have no idea why...

This is the "use starts at the crate root" thing. If you move the "extern crate", then the place it ends up in the module hierarchy is different, and so it breaks.

I always leave "extern crate" in the crate root; then it all Just Works.

The convention is to always keep `extern crate`s in the crate root. `use`s get moved around, but `extern crate`s stay put. Think of `extern crate` as if it were a crate-internal `pub use` (because that's kind of what it is!).