PR #5335 added `autobins`, etc for #5330. Nowhere in there is
discussion of `autolib`.
Cargo script disables support for additional build-targets by disabling
discovery.
Except we don't have a way to disable discovery of `autolib`, leading to #14476.
By adding `autolib`, we can continue in that direction.
This also allows us to bypass inferring of libs on published packages,
like all other build-targets which were handled in #13849.
As this seems fairly low controversy, this insta-stabilizes the field.
In prior versions of Cargo, users will get an "unused manifest key"
warning.
For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal.
For `cargo vendor`, the same except there will be some churn in the
vendored source as this field will now be set.
For local development, it should be rare to set `autolib` so the lack of
error by discovering a file when this is set shouldn't be a problem.
Fixes#14476
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g., `cargo metatada`, status messages,
`SourceID` will display in the v4 URL encoded format.
This shouldn't affect the majority of Rust users,
as `SourceId` representation should be opaque to them,
unless comparing `SourceId` across different version of toolchains.
This changes the registry validation slightly, adding in a check
forbidding implicit source replacement. This affects the tests (which
configure a dummy registry for source replacement), so we also weaken
the checks by only erroring for registry issues when there are actually
local dependencies.
Fix: `cargo package` failed on bare commit git repo.
### What does this PR try to resolve?
Fixes#14354
This approach chose to not generate a `.cargo_vcs_info.json` for bare commit git repo.
### How should we test and review this PR?
Compare the test changes before and after the two commits
### Additional information
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>
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.
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.
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.
fix(toml): Convert warnings that `licence` and `readme` files do not exist into errors
### What does this PR try to resolve?
In this PR:
- Changed the warning to a hard error and modified the associated test function;
- Removed what should have been a redundant test function：`publish::publish_with_missing_readme`；
- Since `cargo publish` is preceded by the execution of `cargo package`, the error message in the test `function bad_license_file` needs to be modified.
issue: https://github.com/rust-lang/cargo/issues/13629#license-file-and-readme-pointing-to-a-non-existent-file.
### Additional information
It seems that this is not enough, the current situation is that `cargo package` warns if `package.readme` is an empty string or the wrong file location, but if I cancel `package.readme`, no warning is generated.
I'm wondering if I should judge `package.readme&licence` when executing `cargo package` and return an error if it doesn't exist?
As this has not been done before, your advice is sought.
This could offer performance gains when parsing a published
manifest since the targets don't need to be discovered.
To see this, we'd first need to stop discovering potential targets even when it isn't
needed.
`cargo package -p no-exist` emitt error when the -p `package` not found
### What does this PR try to resolve?
Fixes#13719
If `-p` is used, and the spec doesn't match any member, we emit an error like `cargo publish -p` does.
### How should we test and review this PR?
The first commit add a test to show the issue, the next commit add the check logic to fix it.
### Additional information
For now, this is more for visual consistency.
However, this blocks #13713 as we need to be able to make these paths
comparable to what is included in the package.
With a traditional walk, `.git` will be picked up, and so will be
ignored directories. This commit also doesn't give submodules special
treatment - instead it just tries to open directories as repositories,
or walks them if that fails.
