This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
Takes local dependencies into account when packaging a workspace. Builds
a temporary package registry to provide local dependencies, and overlays
it on the upstream registry.
This adds `--registry` and `--index` flags to `cargo package`. They act
much like the same arguments to `cargo publish`, except that of course
we are not actually publishing to the specified registry. Instead, these
arguments affect lock-file generation for intra-workspace dependencies:
when simultaneously packaging a crate and one of its dependencies, the
lock-file will be generated under the assumption that the dependency
will be published to the specified registry.
Co-Authored-By: Tor Hovland <55164+torhovland@users.noreply.github.com>
This was found during submodule update in rust-lang/rust repo.
```
error: Expected lines did not match (ignoring order):
0 6 Packaging foo v0.0.1 ([..])
1 0 Archiving Cargo.lock
2 0 Archiving Cargo.toml
3 1 Archiving Cargo.toml.orig
4 0 Archiving src/main.rs
5 0 Updating `dummy-registry` index
6 2 note: package `multi v0.1.0` added to the packaged Cargo.lock file, was originally sourced from `[..]`
7 2 note: package `patched v1.0.0` added to the packaged Cargo.lock file, was originally sourced from `[..]`
8 0 Packaged 4 files, 2.1KiB (1.1KiB compressed)
9 -warning: no (git) Cargo.toml found at `target/tmp/[..]/foo/Cargo.toml` in workdir `[..]`
9 +warning: no (git) Cargo.toml found at `build/aarch64-apple-darwin/stage2-tools/aarch64-apple-darwin/tmp/cit/t0/foo/Cargo.toml` in workdir `[..]`
```
Once we support packaging workspaces with dependencies, dependency
packages need to be built before anything is verified. In addition to a
little refactoring, this commit reorders the console messages so that
package metadata (archive size, etc.) is reported before verification
results.
Co-Authored-By: Tor Hovland <55164+torhovland@users.noreply.github.com>
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
As we switch to MSRV-aware resolver, this will help users work out why
MSRV-aware resolving isn't helping them.
This will also make it more obvious if we breaking things when
developing the MSRV-aware resolver.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
This includes `Cargo.lock` in the git dirty check. It explicitly excludes
`Cargo.lock` as an untracked file, since it is not relevant for the dirty check;
it is only checked if it is committed to git.
This also adds `Cargo.lock` to the "did anything modify this" check during
verification. I don't see a reason to exclude it (particularly since ephemeral
workspaces do not save the lock file).
Also add "Archiving: Cargo.lock" to the verbose output.
This changes it so that `cargo package` will make sure the Cargo.lock file is
in sync with the Cargo.toml that is generated during packaging. This has several
points:
- This makes the Cargo.lock more accurately reflect what would be locked
if a user runs `cargo install` on the resulting package.
- In a workspace, this removes irrelevant packages from the lock file.
- This handles `[patch]` dependencies and dual-source dependencies (like
path/version).
- Warnings are generated for any differences in the lock file compared to the
original.
This has a significant change in how `cargo package` works. It now
unconditionally copies the package to `target/package`. Previously this was only
done during the verification step. This is necessary to run the resolver against
the new `Cargo.toml` that gets generated.
