fix(log): Use a more compact relative-time format
This changes logged messages from
```
2023-08-23T01:01:59.922018Z DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
To
```
0.041729583s DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
Benefits
- Less horizontal space taken up in boilerplate
- Easier to compare within a run
Downsides
- Harder to correlate with other processes, like with crates.io server operations
This gives us up to 4 digits for seconds which should be sufficient for cargo build times.
We could make this more compact by dropping the digits of precision from 9 to 6 but that would require a custom Timer which might be a paint to keep in sync between packages.
This changes logged messages from
```
2023-08-23T01:01:59.922018Z DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
To
```
0.041729583s DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
Benefits
- Less horizontal space taken up in boilerplate
- Easier to compare within a run
Downsides
- Harder to correlate with other processes, like with crates.io server
operations
This gives us up to 4 digits for seconds which should be sufficient for
cargo build times.
We could make this more compact by dropping the digits of precision from
9 to 6 but that would require a custom Timer which might be a paint to
keep in sync between packages.
config: merge lists in precedence order
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.
When a list in configuration exists in multiple places, Cargo merges the lists together. The ordering of this merging is unexpected and does not follow the precedence rules that non-list configuration uses.
The current merging order appears to be:
* project-specific `config.toml`
* global `config.toml`
* command-line (`--config`)
* environment variable (`CARGO_*`)
This PR changes the order to follow the precedence rules with higher precedence configuration merging later in the lists.
* global `config.toml`
* project-specific `config.toml`
* environment variable (`CARGO_*`)
* command-line (`--config`)
This aligns with config such as `build.rustflags` where later flags take precedence over earlier ones.
Since `--config` is relatively new, it's unlikely to cause too much breakage by making it come after environment variables.
Switching global and project-specific ordering is more likely to cause breakage, since it's been around longer (reported as an issue in #8128). Projects relying on global configuration flags (in `$CARGO_HOME\config.toml` or in `.cargo/config.toml` further from the project) being merged first in lists will be broken.
For most uses of merged lists (such as `build.rustflags`), if the flags do not conflict with each other, there will be no impact.
Fixes#12506Fixes#8128
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`
