-
Notifications
You must be signed in to change notification settings - Fork 447
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 regex dependency #1817
remove regex dependency #1817
Conversation
I don't think this is quite right: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f5d78ab8f37b6f4fa60dc5f851c8b883 It seems to only return the first character of the user. This seems to do the trick: fn parse_profile_name(line: &str) -> Option<&str> {
let line = line.strip_prefix("[").and_then(|line|line.strip_suffix("]"))?;
let line = line.strip_prefix("profile").unwrap_or(line);
Some(line.trim())
} however, I'd probably add some tests for edge cases. |
Rusoto currently uses the regex crate's default features. Have you explored disabling those? See rust-lang/regex#613 for an example of how to shrink the binary size is if binary size is the concern The trade of I see here is one of complexity added to rustoto when dropping the dependency all together. Regex is fairly common dependency in other crates and applications. The complexity might not be worth it in those cases. |
b8b3db6
to
6084556
Compare
Yep, and actually a bunch (all?) of the tests failed, I just didn't run them on my final version 😬 . Fixed now.
I did not consider it, because the usage of
Could you expand on this thought? I don't see how dropping a dependency could inherently add complexity. If this PR is merged it does not preclude
My motivating scenario is an application which has ~100 direct dependencies with ~500 transitive dependencies, and this was the only direct dependency which depends on |
That's because you shift the burden from the dependency to your codebase, which usually gains more code to maintain. The main function could be perhaps simplified as /// Parses a profile header, returning the profile name.
fn parse_profile_name(line: &str) -> Option<&str> {
let line = line.trim();
if line.starts_with("[") && line.ends_with("]") {
let profile_name = &line[1..line.len() - 1];
Some(profile_name.trim_start_matches("profile "))
} else {
None
}
} Strings are utf-8 encoded and you're guaranteed that those two characters are 1 byte long (please correct me if I'm wrong). It avoids the repetition of "profile " which could lead to typos in one of them. It reduces wrongly |
Great, I think we're in agreement.
Yep all the characters here are guaranteed to be 1 byte, but string slicing is fraught enough that I prefer to provide offsets as
I agree, |
I am generally fine with very recent MSRVs. (We moved to |
The dependency on `regex` showed up in the `cargo bloat` profile of a large application I work on, and `rusoto` is the only crate which depends on it. It appears that `rustoto`'s use of it is very light, so this PR removes the regex dependency and replaces it with some simple string splitting logic.
6084556
to
1212b94
Compare
regex
showed up in thecargo bloat
profile of a large application I work on, andrusoto
is the only crate which depends on it. It appears thatrustoto
's use of it is very light, so this PR removes the regex dependency and replaces it with some simple string splitting logic.No tests are included, but I believe this functionality is already tested by the sample configs in the test suite.
Please help keep the CHANGELOG up to date by providing a one sentence summary of your change:
regex
dependency.