Skip to content
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

Remove byteorder-dependency #110

Closed
wants to merge 1 commit into from
Closed

Remove byteorder-dependency #110

wants to merge 1 commit into from

Conversation

lukaslueg
Copy link

This removes the byteorder-dependency, which is unneeded in recent stable rust and is pulled in a lot via base64.

Notice that the .unwrap()s reflect the previous behavior, as byteorder would panic implicitly in the same situations.

@marshallpierce
Copy link
Owner

I just moved the lowest supported rust version to 1.31, since that's where the 2018 edition started (from 1.27), and 1.31 doesn't have this. That said, if you can make a compelling case for bumping the lowest supported version of rust, I'm not opposed to it.

@lukaslueg
Copy link
Author

There is in fact no strong case except general ecosystem hygiene; I'm going around removing byteorder here and there since it shows up in the deplist so very often.

Beware that due to TryInto the minimum version would raise to 1.34.

Put it on the shelf if so desired.

@marshallpierce
Copy link
Owner

OK. This is a good change; let's leave it just as is for a couple weeks and let people weigh on supporting old rust vs fewer dependencies.

Do people use old stable rust? I suppose some people must; I don't.

@marshallpierce marshallpierce mentioned this pull request Aug 1, 2019
@stevenroose
Copy link

I don't think a crate like base64 can justify requiring such a new version of the compiler.

@lukaslueg
Copy link
Author

I tend to disagree: Rustc is moving fast, yet it has proven to be very stable. There is simply no reason - unlike with GCC - to dwell on older compiler releases. Other dependencies by upstream will cause the minimum Rust version to be recent-lish, even if base64 falls behind. Besides, 1.34 was released four months ago; it is even in Debian buster.

@stevenroose
Copy link

Well, Debian Buster is only 2 months old, so the majority of Debian users are probably on Jessie, which has Rust 1.24.

Also, in high-assurances environments, it's common to perform an audit on a software stack and stick to it because re-auditing costs a lot of time and money. That's part of the reason why things like LTS distros exist.

Let me refer to this comment for more context: #112 (comment)

Anyway, I'm not against removing the byteorder dependency, but I'm not strongly in favor either. byteorder is one of the good examples of a crate that does a simple thing, is very stable and is compatible with very old Rust versions.

@marshallpierce
Copy link
Owner

Done via #111.

@lukaslueg lukaslueg deleted the byteorder_removed branch September 3, 2019 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants