Package workspaces
Adds support for packaging an entire workspace, even when there are dependencies between the crates. The generated packages should be identical to the ones produced by packaging and publishing the crates one-by-one in dependency order, but the main benefit of this PR is that the packages can be created and verified locally before anything is published.
The main mechanism is the one in #13926, where we create a temporary local registry that "overlays" the true registry. We "publish" the crates in the local registry, which enables lockfile generation and verification of the dependent crates.
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.
You can also publish a subset of a workspace using `-p` arguments. In this case, there will be an error unless the chosen subset contains all of the dependencies of everything in the subset.
Fixes#10948. Based on #13926.
### Compatibility issue
This PR introduces a case where `cargo package` will fail where it did not before: if you have a workspace containing two packages, `main` and `dep@0.1.0`, where `main` depends on `dep@0.1.0` and `dep@0.1.0` is already published in crates.io then attempting to package the whole workspace will fail. To be specific, it will package `dep@0.1.0` successfully and then fail when trying to package `main` because it will see the two different packages for `dep@0.1.0`. Note that `cargo publish` will already fail in this scenario.
This shouldn't interfere with crates.io running `cargo package` for each package to diff the `.crate` files
- This might interfere if someone tried to verify their "published" MSRV by running `cargo package`.
The failure could be avoided by changing the local overlay source to not error out if there's a duplicate package; see [here](https://github.com/rust-lang/cargo/pull/13926#discussion_r1606822615). However, failing early has the advantage of catching errors early.
Don't downgrade on prerelease `VersionReq` when update with --breaking.
### What does this PR try to resolve?
Do nothing with prerelease when update with `--breaking`.
Fixes https://github.com/rust-lang/cargo/issues/14178
### How should we test and review this PR?
Previous commit add a test, next commit to fix and update.
### Additional information
Revert "fix: Ensure dep/feature activates the dependency on 2024"
### What does this PR try to resolve?
Fixes#14283 by re-opening #14016 so we don't block people testing other Edition 2024 changes.
### How should we test and review this PR?
This reverts commit 99fae9187ac0bae12a03585083169e34dc7a197d.
I initially held off on reverting in case we quickly had a clear direction to go. Since we're still doing some investigation, I decided to move forward with this.
### Additional information
Fixes#14283 by re-opening #14016 so we don't block people testing other
Edition 2024 changes.
This reverts commit 99fae9187ac0bae12a03585083169e34dc7a197d.
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>
test: Fix some test based on rustc version
### What does this PR try to resolve?
Some test ouput specifies the latest rustc version and will failed when the rustc version get updated
### How should we test and review this PR?
### Additional information
When browsing the docs, I feel like this will make it easier to tell the
role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and
for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
I was considering moving this into `paths` and noticed `CargoPathExt`.
I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
Fix passing of links-overrides with target-applies-to-host and an implicit target
### What does this PR try to resolve?
This fixes the link-overrides half of #14195, both the panic, and the fact that the field is being discarded, the latter of which caused the former as discussed in [the issue](https://github.com/rust-lang/cargo/issues/14195#issuecomment-2211481773).
It does so following the blueprint laid out in #13900 - which is also in my opinion the current best summary of the broader context.
### How should we test and review this PR?
For reviewing, comparing to the changes in #13900 might be useful.
### Additional information
I'm pushing a PR for the other half of #14195 simultaneously. I thought it better to keep the PRs small since they're independent, though if merged simultaneously there will be a conflict over the ordering of fields in `Unit`.
test: migrate fetch and list_availables to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/fetch.rs`
- `tests/testsuite/list_availables.rs`
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
test: migrate check_cfg to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/check_cfg.rs`
---
This commit allow deprecation for most of the tests currently in this file. This is because the tests either use `does_not_contain` or perform multiple `contains` assertion for single tool with macro `x!`.
Here are some potential options to further eliminate the deprecation:
1. Remove the `x!` macro and replace the it with `str![]` for both Windows and non-Windows platforms.
2. Modify the `x!` macro to only generate the `--check-cfg` part for different platforms and manually compose it with `format!`.
I was changing the "duplicate package" warning to be like:
```
[WARNING] skipping duplicate package `a2 v0.5.0 ([ROOT]/foo/b/../a)`:
[ROOT]/foo/b/../a/a2/Cargo.toml
in favor of [ROOT]/foo/a/a2/Cargo.toml
```
and it showed that we were considering two paths to the same package to
be duplicates.
This suppresses that warning.
