dependencies "contain code that will be rejected by a future version of Rust"

[MightyPork]

I'm getting this warning when built using latest rustc:

warning: the following packages contain code that will be rejected by a future version of Rust: buf_redux v0.8.4, multipart v0.18.0

multipart is abandoned and buf_redux is its abandoned dependency. The cleanest fix would be to switch to something else providing multipart encoding.

I made local forks of the affected crates and fixed it, also upgraded them to 2021 edition.
The fix was trivial, mostly just adding dyn and removing some semicolons in macros.

Here's the patches needed to do that:

buf_redux:

5514df91edd41543afa8b51c51fd3824b66e8b67.diff.txt

multipart:

f56611df6a528ab3141c1f9a047401f2140fb69a.diff.txt

[bradfier]

Thanks for the report @MightyPork - I tend to agree that switching to a maintained provider of Content-Encoding: multipart/* is probably the better solution than carrying around vendored or patched versions of old crates.

I'd accept a PR to do that, otherwise I will look at it myself when I have time.

[bradfier]

This is, unfortunately, more trouble than it initially seemed.

Multipart and buf_redux are direct dependencies and thus fairly easy to swap out, indeed someone already maintains an updated version of buf_redux so I only had to publish an updated crate for the former.

The spanner in the works comes from traitobject which is even more unmaintained than the other two - this gets pulled in by our old-ish version of Hyper so we can't replace it with a fork as easily.

Rouille can't be the only place these new deprecation warnings are showing up so I'll see if there is any information elsewhere about what the suggested migration plan is.

[ravenexp]

Is it possible to make multipart an optional feature instead? Not everyone needs Content-Encoding: multipart/* for their applications.

[bradfier]

Is it possible to make multipart an optional feature instead? Not everyone needs Content-Encoding: multipart/* for their applications.

Yes, but doing so is a breaking change and requires a 4.0 to do so - and I don't really think it's worthwhile for that.

Regardless you'd still be caught out by the hit on traitobject as it's via Hyper, a mandatory dep.

[ravenexp]

Regardless you'd still be caught out by the hit on traitobject as it's via Hyper, a mandatory dep.

I don't have either of these in my dependency tree:

├── rouille v3.6.2
│   ├── base64 v0.13.1
│   ├── chrono v0.4.26
│   │   ├── iana-time-zone v0.1.57
│   │   └── num-traits v0.2.15
│   │       [build-dependencies]
│   │       └── autocfg v1.1.0
│   ├── filetime v0.2.21
│   │   ├── cfg-if v1.0.0
│   │   └── libc v0.2.147
│   ├── multipart v0.18.0
│   │   ├── buf_redux v0.8.4
│   │   │   ├── memchr v2.5.0
│   │   │   └── safemem v0.3.3
│   │   ├── httparse v1.8.0
│   │   ├── log v0.4.19
│   │   ├── mime v0.3.17
│   │   ├── mime_guess v2.0.4
│   │   │   ├── mime v0.3.17
│   │   │   └── unicase v2.6.0
│   │   │       [build-dependencies]
│   │   │       └── version_check v0.9.4
│   │   │   [build-dependencies]
│   │   │   └── unicase v2.6.0 (*)
│   │   ├── quick-error v1.2.3
│   │   ├── rand v0.8.5
│   │   │   ├── libc v0.2.147
│   │   │   ├── rand_chacha v0.3.1
│   │   │   │   ├── ppv-lite86 v0.2.17
│   │   │   │   └── rand_core v0.6.4
│   │   │   │       └── getrandom v0.2.10
│   │   │   │           ├── cfg-if v1.0.0
│   │   │   │           └── libc v0.2.147
│   │   │   └── rand_core v0.6.4 (*)
│   │   ├── safemem v0.3.3
│   │   ├── tempfile v3.6.0
│   │   │   ├── cfg-if v1.0.0
│   │   │   ├── fastrand v1.9.0
│   │   │   └── rustix v0.37.21
│   │   │       ├── bitflags v1.3.2
│   │   │       ├── io-lifetimes v1.0.11
│   │   │       │   └── libc v0.2.147
│   │   │       ├── libc v0.2.147
│   │   │       └── linux-raw-sys v0.3.8
│   │   │   [build-dependencies]
│   │   │   └── autocfg v1.1.0
│   │   └── twoway v0.1.8
│   │       └── memchr v2.5.0
│   ├── percent-encoding v2.3.0
│   ├── rand v0.8.5 (*)
│   ├── serde v1.0.164
│   ├── serde_derive v1.0.164 (proc-macro)
│   │   ├── proc-macro2 v1.0.63
│   │   │   └── unicode-ident v1.0.9
│   │   ├── quote v1.0.29
│   │   │   └── proc-macro2 v1.0.63 (*)
│   │   └── syn v2.0.22
│   │       ├── proc-macro2 v1.0.63 (*)
│   │       ├── quote v1.0.29 (*)
│   │       └── unicode-ident v1.0.9
│   ├── serde_json v1.0.99
│   │   ├── itoa v1.0.6
│   │   ├── ryu v1.0.13
│   │   └── serde v1.0.164
│   ├── sha1_smol v1.0.0
│   ├── threadpool v1.8.1
│   │   └── num_cpus v1.16.0
│   │       └── libc v0.2.147
│   ├── time v0.3.22
│   │   ├── libc v0.2.147
│   │   ├── num_threads v0.1.6
│   │   └── time-core v0.1.1
│   ├── tiny_http v0.12.0
│   │   ├── ascii v1.1.0
│   │   ├── chunked_transfer v1.4.1
│   │   ├── httpdate v1.0.2
│   │   └── log v0.4.19
│   └── url v2.4.0
│       ├── form_urlencoded v1.2.0
│       │   └── percent-encoding v2.3.0
│       ├── idna v0.4.0
│       │   ├── unicode-bidi v0.3.13
│       │   └── unicode-normalization v0.1.22
│       │       └── tinyvec v1.6.0
│       │           └── tinyvec_macros v0.1.1
│       └── percent-encoding v2.3.0

[tgross35]

What is the path forward here?

There is now a somewhat recent RUSTSEC advisory for multipart that is starting to show up wherever Rouille is used. Low severity only, but would be nice to avoid.

[golddranks]

How are Hyper and traitobject relevant here? They don't seem to be dependencies of Rouille.

[ora600pl]

Hi!
Is there any solution for that? I see that it was discussed a year ago, but the current version of rouille ("3.6.2") still raises this warning.

warning: the following packages contain code that will be rejected by a future version of Rust: buf_redux v0.8.4, multipart v0.18.0

[nikolai-franke]

Hello everybody!
I'd love to know if there are any other options than to maintain a fork of the multipart crate? Skimming the internet, it seems like there is no other crate that provides this functionality that isn't asynchronous. As some of the other commenters, I don't fully understand @bradfier's comments about Hyper and the traitobject crate. It would be really nice if you could elaborate on what role Hyper and the traitobject crates play for rouille.

Rouille is basically the only synchronous web framework out there and I really enjoy using it, but it seems like there is no concrete way forward and no simple solution. I'd love to contribute, but simply don't have the skills to maintain a fork of the multipart crate. Basically, my question boils down to this: Does rouille have a future or is now the time to switch to some other web framework?

[golddranks]

I have been seriously thinking of forking Rouille and multiple unmaintained dependent crates. I think there is a place and value for threaded, non-async libraries too.

[bradfier]

Hi folks. I don't have a huge amount of time available to devote to Rouille anymore - I previously worked somewhere that made extensive use of it for backend services, but have since moved on.

To fix this particular issue, a replacement for the deprecated Multipart crate needs to be found. The problem when I tried, was that the maintained crates I found all assumed the use of Hyper and Async, and provided no Sync or standalone functionality. You can of course write a sync wrapper around any trivial async code that doesn't directly interact with a runtime, I simply didn't have the time to do so.

I can continue to read and accept PRs for this, but I can't promise much work on it myself.

[tgross35]

If somebody is willing to do the work, the easiest thing is probably just to duplicate the source of buf_redux and multipart and put them into a crates/ folder in this repo. The fixes are small and done already in this issue's top post. Just applying the fixes and republishing the crates would be much easier than finding a non-async alternative (AIUI there doesn't seem to be one) or completely reworking Rouille to be async (please no 😞 ).