Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo package and cargo publish order of registry selection differ from documentation #14958

Open
YutaoMa opened this issue Dec 18, 2024 · 5 comments
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug Command-package Command-publish regression-from-stable-to-stable Regression in stable that worked in a previous stable release. S-triage Status: This issue is waiting on initial triage.

Comments

@YutaoMa
Copy link

YutaoMa commented Dec 18, 2024

Problem

The Cargo book explains that for cargo publish / cargo package commands, the order by which it decides which registry to publish to is as follows:

  1. --registry CLI arg
  2. package.publish field in Cargo.toml if a single entry
  3. otherwise registry.default key in config

However the current code checks registry.default prior to the manifest file. This causes error like below when both registry.default and package.publish are specified, and no CLI arg is supplied.

% cargo package
error: `demo-registry` cannot be packaged.
The registry `crates-io` is not listed in the `package.publish` value in Cargo.toml

Steps

  1. cargo new demo-registry
  2. In .cargo/config.toml [registry] add default = "crates-io" and some alternative registry
  3. In Cargo.toml [package] add publish = ["some alternative registry"]
  4. Both cargo package and cargo publish fails

Possible Solution(s)

Not sure which is the intended behavior, can either update the code or the documentation. It would be useful to let each crate's own manifest file decide the registry in a workspace setting, so switching the order in code might be better. I tried this change to move default config check after manifest infer and it now works as documented: YutaoMa#1

Notes

No response

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.2.0 [64-bit]
@YutaoMa YutaoMa added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Dec 18, 2024
@epage
Copy link
Contributor

epage commented Dec 18, 2024

Is this reproducible in 1.78? We touched some of this code for workspace packaging and I wonder if this is a regression.

@YutaoMa
Copy link
Author

YutaoMa commented Dec 18, 2024

Verified it's not reproducible in 1.78, it does align with our observation that packages used to pass cargo package started to fail after around 1.82 upgrade

cargo package --allow-dirty
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
   Packaging demo-registry v0.1.0 (/Users/yutma/Developer/demo-registry)
   Verifying demo-registry v0.1.0 (/Users/yutma/Developer/demo-registry)
   Compiling demo-registry v0.1.0 (/Users/yutma/Developer/demo-registry/target/package/demo-registry-0.1.0)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.33s
    Packaged 4 files, 883.0B (676.0B compressed)

@YutaoMa
Copy link
Author

YutaoMa commented Dec 18, 2024

The minimal version to reproduce is 1.82

% rustup default 1.82
info: using existing install for '1.82-aarch64-apple-darwin'
info: default toolchain set to '1.82-aarch64-apple-darwin'

  1.82-aarch64-apple-darwin unchanged - rustc 1.82.0 (f6e511eec 2024-10-15)

% cargo package --allow-dirty
error: `demo-registry` cannot be packaged.
The registry `crates-io` is not listed in the `package.publish` value in Cargo.toml.
% rustup default 1.81
info: using existing install for '1.81-aarch64-apple-darwin'
info: default toolchain set to '1.81-aarch64-apple-darwin'

  1.81-aarch64-apple-darwin unchanged - rustc 1.81.0 (eeb90cda1 2024-09-04)

% cargo package --allow-dirty
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
   Packaging demo-registry v0.1.0 (/Users/yutma/Developer/demo-registry)
    Packaged 7 files, 1.1KiB (930.0B compressed)
   Verifying demo-registry v0.1.0 (/Users/yutma/Developer/demo-registry)
   Compiling demo-registry v0.1.0 (/Users/yutma/Developer/demo-registry/target/package/demo-registry-0.1.0)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.22s

@epage epage added the regression-from-stable-to-stable Regression in stable that worked in a previous stable release. label Dec 18, 2024
@epage
Copy link
Contributor

epage commented Dec 18, 2024

Its a little more informative to verify with cargo publish because cargo package didn't have as many registry checks before, so we could just be seeing an existing publish check moved over to package. Sorry, I hadn't thought to call that out until I saw your test cases.

@YutaoMa
Copy link
Author

YutaoMa commented Dec 19, 2024

NP, it does appear that your theory of existing publish check ported to package seems correct, I can reproduce the error in publish even prior to 1.78

% cargo --version
cargo 1.72.1 (103a7ff2e 2023-08-15)
% cargo publish --dry-run
error: `demo-registry` cannot be published.
The registry `crates-io` is not listed in the `package.publish` value in Cargo.toml.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug Command-package Command-publish regression-from-stable-to-stable Regression in stable that worked in a previous stable release. S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants