Add missing edition
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.
fix(publish): Check remote git registry more than once post-publish
With `publish-timeout` on remote git registries, we were checking once and never checking again. There were 3 layers of guards preventing the cache from being updating
- `needs_update`, handled via `invalidate_cache`
- `config.updated_sources()`,. handled by removing from the HashSet
- `updated`, inaccessible
This change collapses `updated` into `config.updated_sources()`, allowing the cache to be updated
Tested by publishing `epage-publish-test`. After about 7 registry updates, it succeded. Before, it just hit the timeout of 60s. No tests are added as we don't have the plumbing setup to be able to control when the test remote git registry publishes. All of our tests focus on the remote http registry.
Fixes#11253
With `publish-timeout` on remote git registries, we were checking once
and never checking again. There were 3 layers of guards preventing the
cache from being updating
- `needs_update`, handled via `invalidate_cache`
- `config.updated_sources()`,. handled by removing from the HashSet
- `updated`, inaccessible
This change collapses `updated` into `config.updated_sources()`,
allowing the cache to be updated
Tested by publishing `epage-publish-test`. After about 7 registry
updates, it succeded. Before, it just hit the timeout of 60s. No tests
are added as we don't have the plumbing setup to be able to control when
the test remote git registry publishes. All of our tests focus on the
remote http registry.
Fixes#11253
Some tiny refactors around `ops::cargo_compile`
### What does this PR try to resolve?
Some tiny refactors I found during polishing documentations.
- Extract `CompileFilter` and `Packages` from `ops::cargo_compile` to their own modules.
- Remove `FilterRule::try_collect` as its intent is not clear, and we don't need this indirection.
- Remove `CompileOptions::local_rustdoc_args`, which is obsolete since 1ef954ea.
Remove sparse+ prefix for index.crates.io
### What does this PR try to resolve?
#11209 changed how sparse registry URLs are stored in a `SourceId` to remove the `sparse+` prefix, however the URL was not updated.
Fixes#11246
### How should we test and review this PR?
Run a command that requires sparse registry `cargo -Z sparse-registry update --dry-run`
Tests can't really be added for this case, since the `index.crates.io` URL was incorrect, and tests shouldn't access the network.
r? `@Eh2406`
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.
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`
