Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement RFC 3289: source replacement ambiguity #10907

Merged
merged 1 commit into from
Oct 8, 2022
Merged

Conversation

arlosi
Copy link
Contributor

@arlosi arlosi commented Jul 27, 2022

Implements RFC 3289

  • When the crates-io source is replaced, the user needs to specify --registry <NAME> when running an API operation to disambiguate which registry to use. Otherwise, cargo will issue a new error.
  • In source replacement, the replace-with key can reference the name of an alt registry in the [registries] table.
  • Publishing to source-replaced crates.io is no longer permitted using the crates.io token (registry.token). We have had a deprecation warning in place since Several updates to token/index handling. #7973 (1.45.0).

Testing

  • Tests that interacting with crates.io use the new replace_crates_io function, which internally sets an environment variable to change the URL of crates.io.

Changes are insta-stable.

cc #10894
r? @Eh2406

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 27, 2022
@arlosi arlosi force-pushed the sr2 branch 2 times, most recently from 1134053 to 028aa47 Compare July 27, 2022 19:54
Copy link
Contributor

@Eh2406 Eh2406 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code changes themselves are surprisingly small and clear. They look good. Thank you.

However I would like to see tests that explicitly use all the new functionality. Off the top of my head replace-with pointing to a registry. Making sure all the suggested arguments actually work. Making sure that the correct API token goes to the correct server in places where we were doing it wrong before. (And confirming it in the places we were doing it right before.) To be fair maybe these are being tested by existing tests, and I didn't notice in all of the mechanical changes that were required. If so I'm sorry.

On a meta-note: as are reviewing bandwidth continues to be very limited, I want to push to have more of the "obviously correct things" tested. There are very few people who can keep all of the implications of all of cargoes functionality in their head, and at the moment there's only one of them on the team. Inevitably there are gonna be some PR's that are merged without fully realizing all of the implications, the closer we can get to "all the existing tests still pass, so it's safe to ship" the better.

tests/testsuite/publish.rs Outdated Show resolved Hide resolved
crates/cargo-test-support/src/lib.rs Outdated Show resolved Hide resolved
src/cargo/ops/registry.rs Outdated Show resolved Hide resolved
src/cargo/ops/registry.rs Show resolved Hide resolved
@Eh2406
Copy link
Contributor

Eh2406 commented Aug 25, 2022

@arlosi do we have good testing for "Making sure that the correct API token goes to the correct server in places where we were doing it wrong before. (And confirming it in the places we were doing it right before.)"

aside from that, this looks good to me except for the questions about how to test --registry crates-io which I want to leave up to Eric. So

@bors r=@ehuss

@bors

This comment was marked as outdated.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 25, 2022
@bors

This comment was marked as outdated.

bors added a commit that referenced this pull request Aug 25, 2022
Implement RFC 3289: source replacement ambiguity

### Implements [RFC 3289](rust-lang/rfcs#3289)
* When the crates-io source is replaced, the user needs to specify `--registry <NAME>` when running an API operation to disambiguate which registry to use. Otherwise, cargo will issue a new error.
* In source replacement, the `replace-with` key can reference the name of an alt registry in the `[registries]` table.
* Publishing to source-replaced crates.io is no longer permitted using the crates.io token (`registry.token`). We have had a deprecation warning in place since #7973 (1.45.0).

### Testing
* Tests are updated to add the `--registry dummy-registry` parameter to specify the test registry (otherwise they would get the new error message)
* A few tests that need to verify crates-io-specific configuration use an internal `allow_silent_crates_io_replacement` function to allow the previous behavior of silently replacing crates.io within the testing framework.

Changes are insta-stable.

cc #10894
r? `@Eh2406`
@Eh2406
Copy link
Contributor

Eh2406 commented Aug 25, 2022

@bors r-

@bors bors added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 25, 2022
@bors

This comment was marked as outdated.

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Aug 25, 2022
@Eh2406 Eh2406 added the T-cargo Team: Cargo label Sep 1, 2022
@Eh2406
Copy link
Contributor

Eh2406 commented Sep 1, 2022

The changes look good, and well tested. I would just approve, but this is insta-stable. So I'm going to ask for some checkmarks.

By the way, rereading the RFC I'm not seeing code for "Cargo.toml manifest key publish = <NAME> is not set (only applies for publishing)." But I'm happy to leave that for follow-up.

@rfcbot merge

@rfcbot
Copy link
Collaborator

rfcbot commented Sep 1, 2022

Team member @Eh2406 has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period An FCP proposal has started, but not yet signed off. disposition-merge FCP with intent to merge labels Sep 1, 2022
Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thank you very much!

Can you update the config documentation for replace-with to also mention it can use a name from the [registries] table? here

Just to double-check: What is the behavior of the verification step when crates.io is replaced? Does it resolve using the replaced source, or does it use crates.io? I can't find a test for that scenario, and I vaguely recall discussing this situation, but I don't remember the details.

src/doc/src/reference/source-replacement.md Outdated Show resolved Hide resolved
src/cargo/ops/registry.rs Outdated Show resolved Hide resolved
src/cargo/core/source/source_id.rs Outdated Show resolved Hide resolved
@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 7, 2022
@weihanglo
Copy link
Member

💔 Test failed - checks-actions

This new test needs to disambiguate as well.

fn empty_login_token() {
let _registry = RegistryBuilder::new().build();
setup_new_credentials();
cargo_process("login")
.with_stdout("please paste the API Token found on [..]/me below")
.with_stdin("\t\n")
.with_stderr(
"\
[UPDATING] `dummy-registry` index
[ERROR] please provide a non-empty token
",
)
.with_status(101)
.run();
cargo_process("login")
.arg("")
.with_stderr(
"\
[ERROR] please provide a non-empty token
",
)
.with_status(101)
.run();
}

@Muscraft
Copy link
Member

Muscraft commented Oct 8, 2022

Having the fix for the issue from #11099 in this PR instead of in a separate commit or PR isn't ideal. Since there #11193 was opened to fix the issue from #11099 it might be better to have it merged before this PR.

bors added a commit that referenced this pull request Oct 8, 2022
Use correct version of cargo in test

Fix `cargo_remove::offline` test using wrong version of cargo in test, the local version and calling instance of cargo instead of the one being tested.

Issue discovered in #10907 after merge of  #11099.
@Eh2406
Copy link
Contributor

Eh2406 commented Oct 8, 2022

@bors r=ehuss

@bors
Copy link
Collaborator

bors commented Oct 8, 2022

📌 Commit dd5134c has been approved by ehuss

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 8, 2022
@bors
Copy link
Collaborator

bors commented Oct 8, 2022

⌛ Testing commit dd5134c with merge d9b05a1...

@bors
Copy link
Collaborator

bors commented Oct 8, 2022

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing d9b05a1 to master...

@bors bors merged commit d9b05a1 into rust-lang:master Oct 8, 2022
epage added a commit to epage/cargo that referenced this pull request Oct 11, 2022
Ran into confusion on this when updating rust-lang#11062 to be on top of rust-lang#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.
weihanglo added a commit to weihanglo/rust that referenced this pull request Oct 11, 2022
9 commits in 3cdf1ab25dc4fe56f890e8c7330d53a23ad905d3..b8f30cb23c4e5f20854a4f683325782b7cff9837
2022-10-07 17:34:03 +0000 to 2022-10-10 19:16:06 +0000

- Add more doc comments for three modules (rust-lang/cargo#11207)
- docs: fix (rust-lang/cargo#11208)
- Add completions for `cargo remove` (rust-lang/cargo#11204)
- Config file loaded via CLI takes priority over env vars (rust-lang/cargo#11077)
- Use `#[default]` when possible (rust-lang/cargo#11197)
- Implement RFC 3289: source replacement ambiguity (rust-lang/cargo#10907)
- Use correct version of cargo in test (rust-lang/cargo#11193)
- Check empty input for login (rust-lang/cargo#11145)
- Add retry support to sparse registries (rust-lang/cargo#11069)
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 12, 2022
Update cargo

9 commits in 3cdf1ab25dc4fe56f890e8c7330d53a23ad905d3..b8f30cb23c4e5f20854a4f683325782b7cff9837 2022-10-07 17:34:03 +0000 to 2022-10-10 19:16:06 +0000

- Add more doc comments for three modules (rust-lang/cargo#11207)
- docs: fix (rust-lang/cargo#11208)
- Add completions for `cargo remove` (rust-lang/cargo#11204)
- Config file loaded via CLI takes priority over env vars (rust-lang/cargo#11077)
- Use `#[default]` when possible (rust-lang/cargo#11197)
- Implement RFC 3289: source replacement ambiguity (rust-lang/cargo#10907)
- Use correct version of cargo in test (rust-lang/cargo#11193)
- Check empty input for login (rust-lang/cargo#11145)
- Add retry support to sparse registries (rust-lang/cargo#11069)
epage added a commit to epage/cargo that referenced this pull request Oct 12, 2022
Ran into confusion on this when updating rust-lang#11062 to be on top of rust-lang#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.
epage added a commit to epage/cargo that referenced this pull request Oct 12, 2022
Ran into confusion on this when updating rust-lang#11062 to be on top of rust-lang#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.
bors added a commit that referenced this pull request Oct 12, 2022
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.
@ehuss ehuss added this to the 1.66.0 milestone Nov 6, 2023
@ehuss ehuss mentioned this pull request Feb 12, 2024
bors added a commit that referenced this pull request Feb 12, 2024
Fix old_cargos tests

Some of these tests have bitrotted a bit since they aren't enabled by default. The issues are:

* Change to `config` to `config.toml` shouldn't have been made to this test since old cargos can't read config.toml.
* Cargo's own `Carog.toml` now using dotted keys breaks parsing on some old versions, ignore them.
* `cargo pkgid` is now emitting a different format.
* #13085 changed how packages are published in the testsuite to correctly include the `[features]` table in the generated `Cargo.toml`. This exposed an oversight in the `old_cargos::new_features` test wasn't actually testing things correctly. It now correctly illustrates the errors received in older versions. I have a vague memory of this, but I don't remember why it was done this way.
* #10907 changed the default config to use `[registries]` instead of `[source]` to implement source replacement of crates.io. Older versions can't handle that.

Some of these tests probably should just be deleted, since I don't think they are really bringing much value. Or at least they should have some floor that they won't test under. However, I'm not quite ready to do that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge FCP with intent to merge finished-final-comment-period FCP complete S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-cargo Team: Cargo to-announce
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants