Removing crates available in the test runner

Programming Rust
1

The test runner has a long list of crates which are available for students to use in their submissions. Other crates cannot be used, as the test runner doesn’t have access to the internet. Dependabot flagged many of these crates with security vulnerabilities. This triggered me to prune the list of crates.

I’m looking for feedback if there are some crates I would remove that should be kept instead. The full list is here, 78 removed crates in total. I made a commit almost for every single crate with an reason for removing it. But you don’t need to spelunk in the log, if you’d like to discuss some of my choices, just ask directly here.

I’m going to go over a couple “categories” of reason I think a crate should be removed. And then try to identify a few crates that could be controversial.

Reasons for removal:

  • The crate hasn’t received updates in many years, its dependencies got flagged for security vulnerabilities. (example: bigint)
  • The crate is a profiling tool. These may be useful for students, but only locally. We don’t support using our test runner to do profiling. (example: alloc_counter, pprof)
  • The crate may be fine in other regards, but simply not useful to solve our exercises. (example: binomial-iter, graph traversal algorithms)
  • The crate is a “duplicate”, meaning its functionality is provided by another crate which may be considered better by some metrics like maintenance status, popularity by download numbers, quality of documentation. (example: case, change-case, Inflector → convert_case)
  • The only purpose of the crate is very low level performance optimizations, which our exercises don’t need. (example: optimizing the hash function used by e.g. HashMap using the crate fnv or fine-tuning memory allocations with generational-arena) Maybe this is controversial? Maybe we want students to be able to practice such performance optimizations? Still, they can do so locally. I don’t think there’s a need to submit stuff like that to the test runner.
  • One-off: The crate grapheme literally doesn’t have any source code, it’s just a name squat.
  • The crate very specifically solves the problem posed by our exercise. Using such a crate would defeat the purpose of the exercise. (example: rs_poker)

Potentially controversial removals:

  • rug arbitrary precision arithmetic library. It seems maintained (update 2 months ago), but has system dependencies and I couldn’t even get it to build with a quick try. only 400k lifetime downloads. the functionality is not really useful for our exercises, except maybe for “decimal”, where we expect students to implement this themselves.
  • fancy-regex a regex library supporting backtracking, lookahead. These features are not in the regex crate because they degrade performance significantly. I don’t think any of our exercises require regex. If students want to use regex anyway, the features of the standard crate should be plenty, our exercises don’t involve parsing any complex grammars.
  • I was a little hard on derive macro crates like derivative and enum_derive. The reason being, these derive macro crates increase compile times to the point where the test runner often times out. So using them for submissions isn’t really an option anyway.

Note that the track documentation encourages people to make themselves heard if they’d like to use a crate that’s not currently supported.

2 Likes
2

@ErikSchierboom There don’t seem to be any objections. Do you think we should move forward with the PR?

3

Okay, I’ve approved. Let’s deal with any fallout when there is any :)

4

fingers crossed :)