cargo publish should optionally skip unpublishable packages

[kpreid]

This is about the unstable -Zpackage-workspace feature. Discussion branched from #1169 (comment).

Problem

In a large workspace, there might be many packages to publish, and many packages that should not be published (for development only, or applications that are distributed by means other than Cargo). cargo publish -Zpackage-workspace will attempt to publish the workspace’s default members, whether or not they are marked unpublishable with package.publish = false, and error out if any of them are.

This seems to me a missing feature; it should be possible to choose to use package.publish metadata to control whether a package is selected for publishing.

Proposed Solution

• Alternative 1: Add a new flag (with what name?) which selects packages, from members or default-members, as follows:

  • If a package has package.publish = false, it is not selected.
  • If a package has package.publish = true, it is selected.
  • If neither of the above applies, error out and do not publish anything.

  This flag would be compatible with --workspace but incompatible with --package.

  This version encourages workspace authors to explicitly think about whether each package should be published if they wish to use this feature, which seems to me the best outcome. However, it gives new semantics to package.publish = true, which was previously identical to the field being absent. I think this is a good thing (publishing should be more opt-in, since it is close to irrevocable), but it would be new.

• Alternative 2: Add a new flag --exclude-unpublishable.

  • if a package was selected due to being in default-members or due to --workspace being passed, and it has package.publish = false, then it is excluded from selection as if by --exclude.
  • If a package was selected by --package and it has package.publish = false, this is still an error.

• Alternative 3: Automatically skip publish = false packages without any specific flag.

  This might be too “DWIM” but it is the behavior I was implicitly expecting when I tried out -Zpackage-workspace for the first time.

Notes

In the status quo, it would be possible to use the workspace’s default-members to control which packages are published. I think this is not sufficient, because default-members should be a package selection which is appropriate for routine development, which will usually be much more common than publishing. In particular, a package whose job is entirely tests should not be published, but should be run by default with cargo test.

@rustbot label +Z-package-workspace

[epage]

This gets into the question of how much cargo publish should be used standalone vs being plumbing as part of a larger release process. If you are getting to the level of having a workspace, you likely need other parts of your process automated as well, like tagging, proper version bumping, etc. With tools like cargo-release, the excluding is managed for you. So do we need it here?

[epage]

Alternative 3: Automatically skip publish = false packages without any specific flag.

This might be too “DWIM” but it is the behavior I was implicitly expecting when I tried out -Zpackage-workspace for the first time.

This was discussed at #1169 (comment)

Currently, cargo publish foo will error if is package.publish = false. We'd need to determine under what circumstances we should error vs skip.

In #1169 (comment), @kpreid also added

to minimize the chance of proceeding with a user error, it shouldn’t be.

[epage]

Alternative 1: Add a new flag (with what name?) which selects packages, from members or default-members, as follows:

There is also interest in making package.publish opt-in, #6153

If we tie logic to publish = true / publish = false, there is also publish = ["registry"].

[epage]

All three options involve magic in a way and a concern I have with that is the defaults for cargo publish: the default is unreversable and there is no confirmation prompt. If we could go back and change it, I would make --dry-run the default and have a confirmation prompt on --execute (like cargo release). In this state, erroring out on unexpected input is much safer than a "guess my intent flag" as users have to go out of there way to be able to review what will happen.