rustup
rustup copied to clipboard
rust-lang
Reconsider recommending `--profile minimal` for CI (or add CI tools to the minimal profile)
Problem you are trying to solve
The official Rust Docker images do not contain clippy and rustfmt. This has been the source of several issues.
As far as I can tell, they haven't been added because the Rust Docker images should only install what is provided by default by rustup (which seems fair). And since rustup recommends the minimal profile for CI, it seems fair that this is the one used by the Rust Docker images (since such Docker images are often used in CI).
However I think this is a bad recommendation. Linting (clippy) and code format verification (rustfmt) are very, very common tasks in CI. Recommending a profile for CI that doesn't have the capacity to lint code or verify its format is bound to eventually lead to problems when users try to do those things (which just happened to me, and probably why there are all those previously mentioned issues in the docker-rust repository).
Solution you'd like
Rustup ought to recommend a profile for CI that includes the capacity to lint and format code. This can be achieved in any number of ways:
- Add rustfmt and clippy to the minimal profile (probably not desirable)
- Recommend the default profile for use in CI.
- Create a new profile specifically tailored to CI that includes rustfmt and clippy.
I don't really care which solution is chosen - the point is that given such a recommendation, I think the clear choice for the Rust Docker images would be to use the image that includes rustfmt and clippy, which would solve the problem as stated above and solve the issues in the docker-rust repository.
Notes
No response
Its still not clear what you're trying to solve.
Is it build time in CI?
Is it the issue with having rustup working across multiple layers if you modify components post install?
Certainly default is not a good profile for CI in my view : default includes documentation which is 10's of thousands of files that noone will ever read.
The problem I'm trying to solve is what is mentioned in the linked issues, such as https://github.com/rust-lang/docker-rust/issues/97
Basically, the problem currently is that the official Rust docker image doesn't have clippy and rustfmt installed, which means users have to manually install them. And they often have to do that because CI systems where the docker images are commonly used needs clippy and rustfmt to do linting and code formatting. The point is to decrease complexity and make the docker images more useful by including clippy and rustfmt by default.
Certainly default is not a good profile for CI in my view : default includes documentation which is 10's of thousands of files that noone will ever read.
Perhaps solution 1 or 3 above is more suited then? :) Do you have a preference?
https://github.com/rust-lang/docker-rust/issues/16 is unrelated. It was from before rustfmt was part of the rust-lang/repo and when it was not accessible via rustup.
It's hard to explain why any tool should be added to a "CI toolchain". "Minimal" is, well, minimal, and "default" aims at providing an array of tools that can be useful for a programmer's convenience. Those both seem more coherent, as organizing principles, than "what any given continuous integration suite might need". Sure, clippy is commonly used, but I don't use clippy in CI. A fair number of people use miri in CI. Having to have the LLVM tools is common if you have a bindgen or cross-lang LTO scenario. Certainly, I usually need that one. Actually, I'm often rebuilding std in CI for various reasons... Would the "CI profile" be just "the complete toolchain, minus docs", then?
I think stuff like Miri and the LLVM tools shouldn't be in a CI profile by default. Those are only useful when writing unsafe code or FFI probably.
I'd say the default profile but without docs would be a good candidate for a CI profile.
I think the official rust docker images may have a different use case than the default rustup install.
The docker image isn't mutable: rustup can't add components because we move, not copy, and don't fallback (whether we should or not is only tangential here). Point is, having a docker layer that is used for building software (which by definition the rust image is), and that doesn't have fairly small useful packages is less useful than it could, and arguably should be.
I'd be in favour of the docker image defaulting to the minimal profile + rustfmt, clippy; and a second image with every tool but still no docs. The former for a compromise between smallest possible layer size and the overhead of pulling the image, uninstalling the toolchain, adding the toolchain with extra tools; and the latter offering everything in a no-fuss config for users.
I think stuff like Miri and the LLVM tools shouldn't be in a CI profile by default. Those are only useful when writing unsafe code or FFI probably.
And clippy is only useful if you actually think its lints are useful to gate CI on, which many programmers do not. And many repos which still need CI do not run format checks because they simply aren't getting enough multi-programmer action that those are worth the cognitive overhead to install, nevermind deal with on every PR.
I'm not trying to say that there shouldn't be a Docker image including those tools. I think there should be! I'm just saying it doesn't make sense to change the "minimal" profile from meaning anything but, well, minimal, and it's hard to say what a "ci" profile would include as an organizing principle. And I think I undersold the LLVM tools: they include a lot of neat useful stuff, like a disassembler that supports all our targets and lld. Yes, there's ways to use that in CI.
Mostly: I don't think Rustup should be responsible for how every programmer dresses themselves, so to speak. But I think it makes sense to say the Docker images should be a nicely-fitting off-the-rack dress. Or suit. Or suit-dress. And if the current fashion is "with rustfmt and clippy", then yes, it should be fashionable!
We can weaken the recommendation slightly in Rustup's manual and then explain a bit more why each profile might be wanted.
I mean, it's not hard to do rustup component add ... in CI, right? Like it'd be nice for us to have a profile for all use case but it's "just" a convenience feature, no?
And clippy is only useful if you actually think its lints are useful to gate CI on, which many programmers do not. And many repos which still need CI do not run format checks because they simply aren't getting enough multi-programmer action that those are worth the cognitive overhead to install, nevermind deal with on every PR.
I think it's also to do with the principle of least astonishment. Clippy and rustfmt are included with a Rust installation by default. If I get the Rust docker image, I would expect those tools to also be available.
I'm not trying to say that there shouldn't be a Docker image including those tools. I think there should be! I'm just saying it doesn't make sense to change the "minimal" profile from meaning anything but, well, minimal, and it's hard to say what a "ci" profile would include as an organizing principle.
I honestly don't think it's that hard? 🤷 Default without docs sound very reasonable and expected to me. But maybe that's just me. I agree minimal should mean minimal, but currently rustup just offers no good profile for CI. Any solution that would lead to an official Rust docker image that includes clippy and rustfmt would leave me happy :)
It would weird me out, in principle, to add a profile named something like "ci" that doesn't include most of the tools I actually use in CI. :shrug:
And that makes me a bit wary because that hints how subjective the choice is and people love to open issues about various more... "subjective" implementation details of Rust or Rustup. Issues which are not easily resolved and often involve long discussions while trying to find out what they want as they make increasingly strident demands. Sometimes about petty-seeming things. While the Rust CoC may prohibit being a jerk, I like the mods and I would hesitate at making more work for them, or for anyone else working on Rustup.