Publish from parent workspace

[ufoscout]

This PR deals with #1169

The proposed implementation simply loops all the members of a workspace and publish them in the declared order.
Limitations:

• cargo publish --dry-run fails if a member has path dependencies; nevertheless, running it without --dry-run will work as expected (because the referred package will be published beforehand)
• Due the cargo package limitations, it is not possible to upload all the packages together at the end of a global verification, this is because the "path" dependencies need to be present in the repository before the publish process of a package starts.

Please note that these two limitations are not introduced by this PR but are already present in cargo.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Thanks for the PR! I'm unfortunately wary of this sort of construction though. There's a lot of reasons I think that you don't want to publish an entire workspace such as when you have internal crates or some are already at the most recent version. This implementation also doesn't do a topological sort to be publishable to crates.io, perhaps publishing the wrong crate first.

This is a really tricky problem, publishing multiple crates. I think an ideal API might look like cargo publish but with -p arguments to accept of packages to publish, and then Cargo automatically publishes path dependencies that also need publication (perhaps with --publish-deps flag or something like that).

That sort of communication and resolution, however, requires communication with the registry about dependency information and such.

[alexcrichton]

I'm gonna close this for now due to going stale, but we can try to follow up with discussion on the associated issue!

[Charles-Johnson]

I'm trying to automate my release process with GitLab Actions. I want to publish the crates on my workspace sequentially based on their dependencies but the workflow failed: https://github.com/Charles-Johnson/zia_programming/commit/28b744c4ac556eb222dcf85a09c9160c7be3ef56/checks?check_suite_id=407498492. It looks like after I published the first crate it took a while for it to be available on crates.io and caused publishing the second crate to fail.

I guess I could just sleep for an arbitrary amount in between publishing each crate but I wonder if there is a more robust way of doing this.