Can you help me figure how to make this work with Rust 2018?

[wpd]

I know that this crate is in passive maintenance mode, but I care more about space than I do about performance for a web server that is going into an embedded device with very little memory. So I don't want to add the overhead of asyncio.

I am trying to incorporate multipart into my project with:

fn firmware_update_action(mut request: tiny_http::Request, handlebars: &Handlebars) {
    match Multipart::from_request(&mut request) {
        Ok(mut multipart) => {}
        Err(_) => {
            //not_found(request, handlebars);
            return;
        }
    }

but, when I compile (with Rust 1.51, 2018 edition), I get the following error:

error[E0277]: the trait bound `&mut tiny_http::Request: multipart::server::HttpRequest` is not satisfied
   --> src/server.rs:157:35
    |
157 |     match Multipart::from_request(&mut request) {
    |                                   ^^^^^^^^^^^^ the trait `multipart::server::HttpRequest` is not implemented for `&mut tiny_http::Request`
    | 
   ::: /Users/wpd/.cargo/registry/src/github.com-1ecc6299db9ec823/multipart-0.18.0/src/server/mod.rs:87:28
    |
87  |     pub fn from_request<R: HttpRequest>(req: R) -> Result<Multipart<R::Body>, R> {
    |                            ----------- required by this bound in `multipart::server::Multipart::<()>::from_request`

error[E0277]: the trait bound `&mut tiny_http::Request: multipart::server::HttpRequest` is not satisfied
   --> src/server.rs:157:11
    |
157 |     match Multipart::from_request(&mut request) {
    |           ^^^^^^^^^^^^^^^^^^^^^^^ the trait `multipart::server::HttpRequest` is not implemented for `&mut tiny_http::Request`

Can you help me figure out how to address this?

I have this in my Cargo.toml file:

multipart = { version = "0.18.0", features = ["server", "tiny_http" ] }

Part of the reason I chose to implement this server in Rust was to give myself a real life project which I could use to sink my teeth into Rust. So I am stil learning about the language, but this one has me stumped.

[wpd]

Okay... so this doesn't seem to be a Rust 2015/2018 issue. It appears to be a tiny-http 0.6/0.7 issue. I can compile and run your tiny_http.rs example with tiny-http 0.6, but not 0.7. Here's the Cargo.toml file that I used:

[package]
name = "learn-multipart"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
#tiny_http = "0.6.4" # This works
tiny_http = "0.7.0" # this does not
time = "=0.3.5" # version 0.3.6 doesn't compile for us as of 01/24/22 with rust 1.51
multipart = { version = "0.18.0", features = ["server", "tiny_http" ] }

I am still learning Rust... but looking at the differences between 0.6.4 and 0.7.0, I can't see anything related to Request or server that I can understand that would lead to this error.

Do you have any ideas?

--wpd

[abonander]

It's precisely because of the version difference. To the compiler, tiny_http = "0.6.4" and tiny_http = "0.7.0" are two different crates; if you pay attention while running cargo build after a cargo clean, you'll see that Cargo actually compiles both of them.

This is one place that's still a huge source of papercuts in Rust. It's kind of disappointing that they haven't addressed it yet.

[wpd]

Ahhh.... I see... Thank you for the explanation. That's surprising. Despite the number of times I have read the SemVer and Cargo Documentation pages, I guess I still haven't internalized them. I'll go read them again. Regardless, I didn't realize that Rust treated a type exported by one version of a crate differently than the same type exported by a different version of the package.

In the mean time... how would you recommend that I address this problem... especially if it seems to be so common?

Would you accept a PR that changed the version for tiny_http to be 0.10.0 or >=0.6, provided that cargo test (and cargo clippy?) pass successfully? Oh yeah, and provided that it solves my problem for me :-) I'm going to try that later today or tomorrow.

[michalfita]

This is one place that's still a huge source of papercuts in Rust. It's kind of disappointing that they haven't addressed it yet.

Yes & no. Most problems are with immature crates with versions prior to stable 1.x.y. Normally, if you specify your dependencies as 1.x and your dependencies do the same, cargo will automatically pick common version, where y matches. Thing is immature crates raise minor version quite quickly, and people aren't quick enough with updating their dependencies.