cargo package --package includes all packages if no match is found

[paolobarbolini]

Problem

cargo package --package PACKAGE_NAME packages all workspace members if PACKAGE_NAME matches no package. cargo publish --dry-run --package PACKAGE_NAME throws an error instead if no package is found.

Steps

1. git clone https://github.com/RustCrypto/traits.git
2. cd traits
3. git checkout dadaf3591795ba0820080ca45d0feaabd5303ded
4. cargo package --package doesnt-exist: see how it builds all packages
5. cargo publish --dry-run --package doesnt-exist: see how it throws an error

Possible Solution(s)

Make cargo package behave the same as cargo publish --dry-run

Notes

No response

Version

cargo 1.79.0-nightly (0637083df 2024-04-02)
release: 1.79.0-nightly
commit-hash: 0637083df5bbdcc951845f0d2eff6999cdb6d30a
commit-date: 2024-04-02
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/3.2.1)
ssl: OpenSSL 3.2.1 30 Jan 2024
os: EndeavourOS Rolling Release (rolling) [64-bit]

[ehuss]

It looks like this has been an issue since cargo package gained the -p flag.

I think the issue is around here. The members_with_features function has a peculiar behavior when given a spec that is not a workspace member. It will return all workspace members, because that behavior is needed for doing resolution (and handling the case where cargo build -p some_dependency is used). There probably should be some function similar to members_with_features or a separate argument that will generate an error if any of the specs does not match a workspace member.

This is sort of similar to #10677 (#10536), though publish behaves differently because it is restricted to just one package. I believe that was fixed by adding specs[0].query(member_ids)?;. members_with_features might be better suited to enforce that?

We might want to audit to see if there are any other commands that are only intended to work on workspace members have similar problems.

[linyihai]

@rustbot claim