EmbarkStudios
`--locked` default behavior
Follow up from the discussion started in #341.
I've now added support for --frozen, --locked, and --offline (which also disables advisory database fetching). I plan on exposing these flags in the Github Action as well.
As far as the defaults are concerned, I think it makes sense to separate the 2 main use cases of cargo-deny, which in my mind are
- Local use by a regular user
- Automated, typically CI
For the local use case, I think the defaults should be consistent with how other cargo subcommands work, which for each of those flags is an opt-in that the user makes a conscious decision to add. While it would be best if cargo-audit also followed this behavior (IMO), I'm not super concerned with that tool being different, as (I assume) you would either use cargo-deny or cargo-audit in a project, but not both.
For the automated use case, the use of opt-in flags means they are explicit and (hopefully) greppable in the VCS and/or automation configuration and gives the maximum flexibility in terms of how the automation is setup. The drawbacks of being explicit are of course that an actual decision needs to be made when setting up the automation to eg. pass --locked.
So there is definitely a conflict between the normal cargo default of needing to opt-in to --locked, but in CI a project will generally want to enable --locked (as well as the others if wanting to be network sandboxed), and either have a checked-in lockfile, or have an explicit lock generation step before cargo-deny is executed.
I think that one fairly simple solution to this conflict is to expose these 3 flags in the normal cargo-deny configuration, so that each project can configure them for all uses cases by default so that the local and automated use case match each other. This kind of goes against my point above about cargo-deny acting the same as other cargo subcommands, but I think this feels like a decent compromise between wanting to be consistent between usecases using a configuration file that a cargo-deny user will already need to create/edit anyhow, and already has eg. targets as a top-level field to influence the resolution behavior of the crate graph.
CI systems usually expose CI=1 env var. We could use that to produce a warning that users should use --locked when running automation (this warning should probably have means for suppression in the deny.toml), otherwise the CI runs may be flaky (fail randomly).
I believe that following the behavior of cargo here should be the default, but the users may just be provided with warnings to assist in preventing unconscious improper use.
However, exposing the flags in the config also LGTM, I think we can do both (a warning and extending the config file).
Please note that some projects do not have a Cargo.lock. For example, library crates don't usually commit the lockfile, and having --locked for them by default would not be correct, I guess?
Correct, using --locked or --frozen would require that projects without a lockfile would need to generate it beforehand, but that is a fairly easy thing to error one with instructions, particularly in an automated script.
I raised the idea of using the CI environment variable (which AFAIK all popular CI systems set) in https://github.com/EmbarkStudios/cargo-deny/issues/341#issuecomment-871745873 but a fair point was made that doing that would be an implicit behavior difference between the local and automated usecase. But that being said, the configuration for using locked/frozen/offline could be made to respect if certain environment variables exist/set to a specific value, which again would be an explicit and greppable file in VCS which would mitigate the implicit difference problem.