fix: Change the defaults to always check-in `Cargo.lock`
### What does this PR try to resolve?
Having libraries leave `Cargo.lock` "on the float" has been serving the ecosystem well, including
- Encouraging people to validate that latest dependencies work
- Encouraging ecosystem-wide health by acting as a "distributed crater"
These benefits are limited though. The policy is inconsistent between workspaces with or without `[[bin]]`s, reducing the affect of testing the latest. This is also subject to when CI last ran; for passively maintained projects, there is little coverage of new dependencies.
There are also costs associated with this policy
- `git bisect` is using an unpredictable set of dependencies, affecting the ability to identify root cause
- This is another potential cause for Red CI / broken local development if version is yanked or a bug is introduced
- Impacting the perceived level of quality for a project
- Confusing to new contributors who might not recognize why CI failed and assume its their fault
- Requiring context switching from maintainers to get fixes in
In particular, since this policy was decided, there has been an increased interest in supporting an MSRV (as recently as v1.56.0, cargo gained support for specifying a package's MSRV). This has led to long discussions on *what* MSRV a package should use (e.g. rust-lang/libs-team#72,. time-rs/time#535). Worst, there has been a growing trend for people to set an non-semver upper bound on dependencies, making it so packages can't work well with other packages (see #12323). Tooling support would help with this (#9930) but the sooner we address this, the less entrenched bad practices will be.
On the positive side, since the policy was decided
- In general, CI became easier to setup and maintain with Github Actions compared to TravisCI
- Dependabot went GA on Github in 2021 (https://github.blog/changelog/2021-03-31-dependabot-version-updates-are-now-generally-available)
- I believe Dependabot will post security update PRs even when Dependabot is not more generally enabled
So to get some of the benefit from not checking in `Cargo.lock`, we can recommend either automatically applying updates or having CI check the latest dependencies in a way to get this out of the critical path of PRs and releases.
Since there is no one right answer on how to solve all of these problems, we're documenting these trade offs so people can make the choice that is most appropriate for them. However, we are changing the default to a consistent "always check it in" as the answer for those who don't want to think about it.
Prior art
- [Yarn (Javascript)](https://yarnpkg.com/getting-started/qa#should-lockfiles-be-committed-to-the-repository)
- [Poetry (Python)](https://python-poetry.org/docs/basic-usage/#committing-your-poetrylock-file-to-version-control)
- [Bundler (Ruby)](https://bundler.io/guides/faq.html#using-gemfiles-inside-gems)
Fixes#8728
### How should we test and review this PR?
Please review per-commit. I tried to minimize changes I made to the structure of the CI document
In #8728, I brought up having a CI reference page. I keep going back and forth on whether this is guide-level material or reference-level material. Obviously, right now I'm leaning towards it being guide-level.
### Additional information
This changes cargo from telling people what to do to giving them a starting point, or default, and giving them the information to make their own choice, if needed.
So the question for defaults is who are we targeting? For a default path in documentation, it would be for new to intermediate users. As for `cargo new`, we've been prioritizing new users over those that run it frequently (boiler plate comment, bin is default, etc).
See #8728 for the FCP on this policy change
chore: Downgrade serde below the binary blob
As of serde 1.0.172, `serde_derive` ships a binary blog for Linux x64 for faster build times. This blob is not yet reproducible to ensure that the safety of it. See serde-rs/serde#2538. See also https://diff.rs/serde_derive/1.0.171/1.0.172/Cargo.toml
This is not a judgement on serde or on dtolnay but just a precaution to buy us more time as the community works through this since the beta cut is coming up. rust-1.72 branch is unaffected.
As of serde 1.0.172, `serde_derive` ships a binary blog for Linux x64
for faster build times. This blob is not yet reproducible to ensure
that the safety of it. See serde-rs/serde#2538
This is not a judgement on serde or on dtolnay but just a precaution to
buy us more time as the community works through this since the beta cut
is coming up. rust-1.72 branch is unaffected.
Improve error message for when no credential providers are available
If no credential providers are available (because they all said `UrlNotSupported`), add a new error message "no credential providers could handle the request". Previously this said, "credential not found".
* Add test for all credential providers saying `NotFound`
* Add test for all credential providers saying `UrlNotSupported`
Make cargo-credential-gnome-secret built-in as cargo:libsecret
We previously couldn't have cargo-credential-gnome-secret built into Cargo because of its build-time dependency on `libsecret`. However, this limitation has now been lifted by #12518.
Adds a new built-in credential provider `cargo:libsecret`.
Adds `ISC` as an allowed license for `libloading`.
* `rustc` already uses `libloading`
* ISC license is very similar to MIT
Renames the crate from `cargo-credential-gnome-secret` to `cargo-credential-libsecret` and changes the crate structure to more closely match `wincred` and `macos-keychain`.
login: allow passing additional args to provider
As part of moving asymmetric token support to a credential provider in #12334, support for passing `--key-subject` to `cargo login` was removed.
This change allows passing additional arguments to credential providers when running `cargo login`. For example:
`cargo login -- --key-subject foo`.
The asymmetric token provider (`cargo:paseto`) is updated to take advantage of this and re-enables setting `--key-subject` from `cargo login`.
r? `@Eh2406`
cc #8933
cargo-credential-gnome-secret: dynamically load libsecret
Building `cargo-credential-gnome-secret` currently requires the `libsecret` development libraries to be installed and findable via `pkg-config`. This is often an extra step for users and complicates CI builds.
This loads the required functions from `libsecret` dynamically using `libloading` which uses `dlopen` internally.
Closes#12503
Testing this requires manually installing the credential provider on a system with libsecret set up. I tested it on Arch Linux.
credential-providers: make 1password no longer built-in
Since 1password is just one of many potential CLI-based credential providers, it makes more sense for it to be installable as a plugin rather than built-in to Cargo.
This means that `cargo:1password` will no longer work as a credential provider.
The replacement would be `cargo install cargo-credential-1password` and using `cargo-credential-1password` instead.
r? `@ehuss`
credential: rename cargo:basic to cargo:token-from-stdout
Multiple people have said that the name of the `cargo:basic` credential provider is confusing, since it's not doing HTTP Basic authentication.
Rename `cargo:basic` to `cargo:token-from-stdout`, which more accurately describes what it does.
When merging configuration lists, the current order does not match
the expected precedence. This makes merged lists follow precedence
order, with higher precedence items merged later in lists.
versions and paths of a workspace members between the original and
a checked-out workspace are different, and shouldn't be included in
hash keys when querying packages.
The `github.sha` is a merge commit with the parents of latest master
and the head of the pr. Trying to diff the changes from that merge
SHA to base will show all changes that have been made in-between.
And that doesn't seem about right.
We switch to `github.event.pull_request.head.sha` if there is a pr.
See: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/version-bump.20CI.20failing
Crate checksum lookup query should match on semver build metadata
Since crates.io allows crate versions to differ only by build metadata, a query using `OptVersionReq::exact` + `next()` can return nondeterministic results.
This change fixes the issue by adding an additional `filter` that ensures the version is equal (including build metadata).
It still feels somewhat wrong that a query using `exact` can match multiple crates, so an alternative fix would be to add a new variant of `OptVersionReq` that also matched on build metadata.
Fixes#11412
