Document `cargo remove`
### What does this PR try to resolve?
This PR continues the deferred work of #11099 by adding documentation for the cargo remove subcommand.
### How should we test and review this PR?
Ensure that the documentation renders correctly and appropriately covers the feature.
Originally, crates.io would block on publish requests until the publish
was complete, giving `cargo publish` this behavior by extension. When
crates.io switched to asynchronous publishing, this intermittently broke
people's workflows when publishing multiple crates. I say interittent
because it usually works until it doesn't and it is unclear why to the
end user because it will be published by the time they check. In the
end, callers tend to either put in timeouts (and pray), poll the
server's API, or use `crates-index` crate to poll the index.
This isn't sufficient because
- For any new interested party, this is a pit of failure they'll fall
into
- crates-index has re-implemented index support incorrectly in the past,
currently doesn't handle auth, doesn't support `git-cli`, etc.
- None of these previous options work if we were to implement
workspace-publish support (#1169)
- The new sparse registry might increase the publish times, making the
delay easier to hit manually
- The new sparse registry goes through CDNs so checking the server's API
might not be sufficient
- Once the sparse registry is available, crates-index users will find
out when the package is ready in git but it might not be ready through
the sparse registry because of CDNs
So now `cargo` will block until it sees the package in the index.
- This is checking via the index instead of server APIs in case there
are propagation delays. This has the side effect of being noisy
because of all of the "Updating index" messages.
- This is done unconditionally because cargo used to block and that
didn't seem to be a problem, blocking by default is the less error
prone case, and there doesn't seem to be enough justification for a
"don't block" flag.
The timeout was 5min but I dropped it to 1m. Unfortunately, I don't
have data from `cargo-release` to know what a reasonable timeout is, so
going ahead and dropping to 60s and assuming anything more is an outage.
Fixes#9507
feat(publish): Support 'publish.timeout' config behind '-Zpublish-timeout'
Originally, crates.io would block on publish requests until the publish
was complete, giving `cargo publish` this behavior by extension. When
crates.io switched to asynchronous publishing, this intermittently broke
people's workflows when publishing multiple crates. I say interittent
because it usually works until it doesn't and it is unclear why to the
end user because it will be published by the time they check. In the
end, callers tend to either put in timeouts (and pray), poll the
server's API, or use `crates-index` crate to poll the index.
This isn't sufficient because
- For any new interested party, this is a pit of failure they'll fall
into
- crates-index has re-implemented index support incorrectly in the past,
currently doesn't handle auth, doesn't support `git-cli`, etc.
- None of these previous options work if we were to implement
workspace-publish support (https://github.com/rust-lang/cargo/issues/1169)
- The new sparse registry might increase the publish times, making the
delay easier to hit manually
- The new sparse registry goes through CDNs so checking the server's API
might not be sufficient
- Once the sparse registry is available, crates-index users will find
out when the package is ready in git but it might not be ready through
the sparse registry because of CDNs
This introduces unstable support for blocking by setting
`publish.timeout` to non-zero value.
A step towards #9507
Add missing edition
### What does this PR try to resolve?
When I read this doc, I found that we are missing the edition key in this manifest. I think we should add it because `cargo new` always does this.
Originally, crates.io would block on publish requests until the publish
was complete, giving `cargo publish` this behavior by extension. When
crates.io switched to asynchronous publishing, this intermittently broke
people's workflows when publishing multiple crates. I say interittent
because it usually works until it doesn't and it is unclear why to the
end user because it will be published by the time they check. In the
end, callers tend to either put in timeouts (and pray), poll the
server's API, or use `crates-index` crate to poll the index.
This isn't sufficient because
- For any new interested party, this is a pit of failure they'll fall
into
- crates-index has re-implemented index support incorrectly in the past,
currently doesn't handle auth, doesn't support `git-cli`, etc.
- None of these previous options work if we were to implement
workspace-publish support (#1169)
- The new sparse registry might increase the publish times, making the
delay easier to hit manually
- The new sparse registry goes through CDNs so checking the server's API
might not be sufficient
- Once the sparse registry is available, crates-index users will find
out when the package is ready in git but it might not be ready through
the sparse registry because of CDNs
This introduces unstable support for blocking by setting
`publish.timeout` to non-zero value.
A step towards #9507
refactor(publish): Clarify which SourceId is being used
Ran into confusion on this when updating #11062 to be on top of #10907. This now threads both types of sources through which comments explaining each so callers will always have to explicitly acknowledge which they are dealing with.
Fix deadlock when build scripts are waiting for input on stdin
### What does this PR try to resolve?
#10738 introduced a regression where build scripts did not close stdin, causing deadlocks for build scripts waiting for stdin.
Fixes#11196 by not piping `stdin` unless requested by the `ProcessBuilder`.
### How should we test and review this PR?
Run a build script that reads from stdin and check that it no longer hangs. See the POC in the linked issue. The included test hangs without the fix.
r? `@ehuss`
Fix rustdoc warning about unclosed HTML tag
nightly rustdoc is warning about `<name>` being an unclosed HTML tag. Fix by using backticks instead of single quotes.
Ran into confusion on this when updating #11062 to be on top of #10907.
This now threads both types of sources through which comments explaining
each so callers will always have to explicitly acknowledge which they
are dealing with.
refactor(tests): Prepare for wait-for-publish test changes
In #11062, we are updating `cargo publish` to wait until a package is published. The problem is a lot of our tests will block until the timeout. In finding the tests to update, I was originally relying on test failures from the extra output when timing out. The problem is not all tests verify the test output so they don't fail.
This tries to update the tests to make the introduction of a timeout more obvious.
- Adding `with_stderr` where it wasn't before
- Moving away from `with_stderr_contains` for publish tests
To help with that, I made the predicates on cargo commands more consistent.
I also moved descriptions of tests to be outside of the test so I can more easily document the `registry::init` calls with what we are doing.
Add configuration option for controlling crates.io protocol
### What does this PR try to resolve?
Currently, if `-Z sparse-registry` is passed, then Cargo will access crates.io using the sparse protocol. Since we want to stabilize this feature soon, we need a stable way to control which protocol is used.
This adds a config option `registries.crates-io.protocol` that can be set to either `sparse` or `git`. If the option is unset, it will be `sparse` if `-Z sparse-registry` is enabled, otherwise it will be `git`.
This PR does not stabilize `sparse-registry`. Using `registries.crates-io.protocol` without `-Z sparse-registry` will result in an error.
The next steps after PR are to:
* stabilize `sparse-registry`
* make `sparse` the default protocol
### Additional information
The config option is based on the discussion in this note: https://hackmd.io/`@rust-cargo-team/B13O52Zko`
Arlo Siemsen
Weihang Lo
bors
Ed Page
Cassaundra Smith
Basile Henry
hi-rustin
Scott Schafer
Tshepang Mbambo