4 ms·
I am not sure if this directly applies to your post, but it came to mind when I read the section about `extern crate`. It seems like the Cargo system is relied
by no_protocol 10y ago
I am not sure if this directly applies to your post, but it came to mind when I read the section about `extern crate`. It seems like the Cargo system is relied upon by almost all Rust users, and I am not sure if the following is an ergonomics problem or a lack of understanding on my part.
A couple months ago I was exploring Rust's web server capabilities after seeing the "Are we web yet?" page. I decided to try out the `iron` package.[0]
I was quickly able to serve some basic content, but I wanted to add some headers to the response.
I was able to `use iron::headers::Allow` to add an Allow header.[1]
Next, I wanted a Link header. Link wasn't available but I could get around that by defining a custom header with the `header!` macro. Unfortunately, I couldn't figure out how to get the `header!` macro for custom headers without `#[macro_use] extern crate hyper` and adding `hyper` to the Cargo.toml file.[2]
Then I wanted a `Vary` header. I was able to get that in with `use iron::headers::Vary`, but I couldn't actually create one yet! In order to create my `Vary::Items` header, I needed to also `use unicase::UniCase` and add `unicase` to my Cargo.toml.[3][4]
So within an hour or so of starting the project, my explicitly listed dependencies had grown from just `iron` to include two additional dependencies. The iron package already relies upon hyper which already relies upon unicase.
Here are some questions I am still left with. Would love any responses.
Is it possible for me to use the pieces described above without explicitly listing these crates? If not, why do I need to declare hyper as a dependency when iron is already using it? Perhaps I don't need to, and I was just unable to figure out how to get the `header!` macro from iron directly. My initial expectation was that iron would either wrap or expose every part of hyper that I might need. The same goes for hyper not allowing me to just use the same unicase it relies upon.
How am I supposed to get the correct version of hyper and unicase to match with the ones that my version of iron was sent with? Do I have to go look them up? Can use the latest version of `hyper` even if `iron` is a few versions behind? What version should I be specifying?
[0]: http://ironframework.io/doc/iron/ http://ironframework.io/doc/iron/
[1]: http://ironframework.io/doc/iron/headers/struct.Allow.html http://ironframework.io/doc/iron/headers/struct.Allow.html
[2]: https://hyper.rs/hyper/v0.9.9/hyper/macro.header!.html https://hyper.rs/hyper/v0.9.9/hyper/macro.header!.html
[3]: http://ironframework.io/doc/iron/headers/enum.Vary.html http://ironframework.io/doc/iron/headers/enum.Vary.html
[4]: http://ironframework.io/doc/unicase/struct.UniCase.html http://ironframework.io/doc/unicase/struct.UniCase.html
- steveklabnik 10y ago> Is it possible for me to use the pieces described above without explicitly listing these crates? Not unless iron exposed them directly. I haven't used it a while, so I'm not sure if it does. > If not, why do I need to declare hyper as a dependency when iron is already using it? There's a difference between a direct and transitive dependency, it's not going to just inherently bring transitive stuff into scope. > Perhaps I don't need to, and I was just unable to figure out how to get the `header!` macro from iron directly. Yeah I haven't used iron in long enough to say, but this is theoretically possible. > My initial expectation was that iron would either wrap or expose every part of hyper that I might need. Yes, it is possible that iron's API isn't the best here.
- tedmielczarek 10y ago> I am not sure if this directly applies to your post, but it came to mind when I read the section about `extern crate`. It seems like the Cargo system is relied upon by almost all Rust users, and I am not sure if this is an ergonomics problem or a lack of understanding on my part. This is definitely true, and I don't think it's negative. You can use Rust without Cargo and crates.io, but it feels very different. It's nice that that option exists, but I wouldn't want to work that way. Any sizeable project is likely to accumulate a large number of crates.io dependencies, but having written a lot of C++ code, the alternatives are "reimplement this thing myself" or "copy paste some code", neither of which are particularly good.
- no_protocol 10y agoOops, I used `this` when I should have said `the following.` I have updated the line in my post above. I wasn't suggesting Cargo being relied upon by everyone was an ergonomics issue, but instead referring to the description in the remainder of my post.
- dogamak 10y agoMacros and the importing and scoping of them is a mess in rust right now and major rewrite of the macro system is underway. Currently crates have no way to re-export macros from other crates and #[use_macros] brings all macros in the imported crate to the local crate's namespace as-is (no way to prevent possible naming conflicts)