-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swap libflate for flate2 #100
Conversation
In the 2018 Rust edition, `extern crate`s are discouraged. Instead, to use macros, one need only import the macro with a standard `use` declaration where required.
flate2 has proven to be the more popular implementation of the DEFLATE algorithm in Rust. Standardizing on the more popular variant means downstream crates don't end up with two separate libraries implementing the DEFLATE algorithm in their crate graph. flate2 also avoids depending upon the adler32 crate, which uses the nonstandard Zlib license. Instead it uses the adler crate, which is licensed under the more common MIT/Apache 2 licenses.
Well, shoot, looks like we need to bump the MSRV to 1.34.0. Is that a dealbreaker? |
Tests are happy with the MSRV bump on my fork, FWIW: https://github.com/benesch/procfs/actions/runs/289607539 |
Hmm, this is a tough call! I told @Nukesor in #98 that I didn't want to change the MSRV to 1.45 (2020-07-16) for an internal implementation detail. But to be honest, I don't really have a well-thought-out policy on this. 1.34 is still fairly old (2019-04-11), and if accepted, this change would be in an upcoming 0.9.0 release (where we'd be able to bump the MSRV). Regarding switching to flate2, I took a look at a bunch of crates that depend on procfs (what I could find by searching github). Most of them didn't have any other flate-related dependencies, but indeed there were a few that had flate2 brought into the dep-tree (thus if procfs switched to flate2, it would be a few less dependencies for upstream crates). Also, flate2 seems to be a tiny bit smaller, which is good too. So I'm probably inclined to accept this, but I welcome thoughts (from anyone reading this issue) on the MSRV topic |
Thanks very much for considering this in such detail, @eminence! There's no particular urgency on my end, so makes total sense if you want to wait a little while longer before bumping the MSRV. |
I took another look at some of the big/important users of procfs, and it turns out that none of them run on 1.33.0, so I'm now more comfortable bumping the MSRV from 1.33 to 1.34. Thus I'm going to merge this change. Stay tuned for an upcoming 0.9.0 release very shortly. Thanks! |
This has now been published on crates.io as |
flate2 has proven to be the more popular implementation of the DEFLATE
algorithm in Rust. Standardizing on the more popular variant means
downstream crates don't end up with two separate libraries implementing
the DEFLATE algorithm in their crate graph.
flate2 also avoids depending upon the adler32 crate, which uses the
nonstandard Zlib license. Instead it uses the adler crate, which is
licensed under the more common MIT/Apache 2 licenses.
@eminence hope this isn't too much to ask. I noticed that test_kernel_config doesn't run in CI, so I manually tested this change on a Gentoo box that had /proc/config.gz, and all was well!