warn when cargo subcommand backing binary is not part of the criticalup installation#176
Conversation
Fixes the test by passing the path to the configuration in the temporary folder. Remove ignore flag. Other tests will be added later based on this test.
968b2c6 to
0e83243
Compare
Backing binary is a binary used by a cargo subcommand. It is resolved from PATH. If ARG is `clippy` or `fmt` and is called via the `criticalup run cargo (--strict) <ARG>` and its backing binary is not present in the criticalup installation emits an warning indicating the package is missing from the criticalup installation.
0e83243 to
2887714
Compare
|
bors try |
tryBuild failed: |
|
bors try |
tryBuild failed: |
|
bors try |
|
bors try |
tryAlready running a review |
|
bors cancel |
|
bors try |
tryAlready running a review |
tryTimed out. |
|
bors try |
tryBuild failed: |
|
bors try |
tryBuild failed: |
|
bors try |
tryBuild failed: |
| if let Some(backing_binary) = cargo_subcommand_map.get(arg.as_str()) { | ||
| if !bin_paths.iter().any(|x| x.join(backing_binary).exists()) { | ||
| tracing::warn!("'{0}' is not installed for this project, and may run from binaries outside the criticalup installation.\n \ | ||
| To prevent this, please make sure that the correct package for '{0}' is listed in the packages section of your \n\ | ||
| project's criticalup.toml and run 'criticalup install' command again.\n", backing_binary); | ||
| } | ||
| } |
There was a problem hiding this comment.
sorry if this has already been discussed
- do we instruct users to always use
criticalup run cargo ...? if not, then maybe the better solution is shimming cargo to detect this problem, which would allowcargo fmtin a ferrocene project to raise this warning - another approach is to install shims for these tools unless requested. the shims will print this message and run the fallback component (is there a tool we can ask to resolve this?). when the user specifically requests the component, then we can provide our installation of the tool
There was a problem hiding this comment.
We document 3 ways of running Ferrocene packages . Only if you run criticalup run cargo subcommand it is possible to use inadvertently a non Ferrocene distributed binary called by the sub-command. The current set of sub-commands affected are clippy and fmt. The current solution has small footprint, and we can revisit it in case we need to manage an increasing number of cases
|
bors try |
tryBuild failed: |
bd07850 to
5b01659
Compare
|
bors try |
tryBuild succeeded: |
|
bors merge |
|
Build succeeded:
|
Emits a warning if:
criticalup run (--strict) cargo clippyis run butcargo-clippyis not installed via criticalup.criticalup run (--strict) cargo fmtis run butrustfmtis not installed via criticalup.Problem
When clippy is available via rustup, but not installed via Ferrocene, running
criticalup run cargo clippywill fallback to using rustup's installed clippy , potentially resulting in crates compiled with an incompatible version of rustc (compared to the version clippy was compiled with).Replication steps
criticalup run (--strict) cargo clippyThe compiler complains of having libraries compiled with an incompatible rustc version
How to test this PR
Note: In this example, if criticalup is linked as a rustup toolchain and used (is active), both a warning and an actual error will be returned. The later is due to the
cargo-clippybinary missing in the path