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

Display registry name instead of registry URL when possible #9632

Merged
merged 6 commits into from
Jul 21, 2021

Conversation

weihanglo
Copy link
Member

Fixes #6691

This PR can be divided into several parts:

  • c5be3de: Try to display registry names instead of URLs for impl Dipslay for SourceId. This benefits almost all kinds of messages usingSourceId directly or indrectly.
  • 9394d48: This fixes Updating <name> index part of [source] replacement, which previously didn't preserve the registry name information.
  • 4c2f9b5: This makes its best effort to show registry names for deps from Cargo.lock. Since current lockfile format does not serialize any registry name. We here try the best effort to restore registry name from either [registries] table or [source] replacement table. This is done by manually implementing Hash and PartialEq for SourceIdInner, of which two traits previously are simply derived.
    To make SourceIdInner generate the same hash no matter it contains name field or not, here we remove name field from hashing and only concern about kind, precise and canonical_url.

Feel free to ask me for adding more tests, though I am not sure what tests should be added 😅

@rust-highfive
Copy link

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 27, 2021
format!("{:?}", pkg_id)
);

let expected = r#"
PackageId {
name: "foo",
version: "1.0.0",
source: "registry `https://github.com/rust-lang/crates.io-index`",
source: "registry `crates-io`",
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not keep the original registry url instead of using a short alias?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's the intent of #6691, which make it less mess in terminal (maybe?). And yes it gets some rooms for deciding whether URL should be hidden.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it isn't an issue since it's less than 80 characters which terminal will usually expect to be the lowest, of course it can go lower but most stuff will look ugly.

    Updating `https://gitlab.com/xxxxxxxxxx/cargo/crates-index` index

If a short alias is used some amount of information is hidden which could be useful in the logs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep. Maybe we can preserve the original behaviour of crates.io, and shorten other custom registries, since we have no idea which contains sensitive information. Is this more reasonable?

Copy link
Contributor

Choose a reason for hiding this comment

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

Is the url sensitive? If it is sensitive shouldn't the user hide it themselves? I think it is not easily missed as it is at the top line, and it does not contain any credentials.

Copy link
Member Author

Choose a reason for hiding this comment

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

I got the point and totally agreed. It's very reasonable not using short alias. Let's await the opinion from others. Maybe we can come up with better solution.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm a bit confused about the question here. Are you just talking about the debug display? That is almost never shown anywhere, so I'm not sure it really matters. It'll probably be safer to keep the short name (like if asked to share CARGO_LOG output). If I'm misunderstanding, can you clarify?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not just debug display, it affects the default cargo display as well. Rather than showing the crates url it shows crates-io.

@bors
Copy link
Collaborator

bors commented Jul 14, 2021

☔ The latest upstream changes (presumably #9665) made this pull request unmergeable. Please resolve the merge conflicts.

@ehuss
Copy link
Contributor

ehuss commented Jul 21, 2021

Thanks! I'm always a bit nervous changing the behavior of SourceId since it is used in so many places with subtle behavior. However, I can't immediately think of any issues here. I guess there might be some edge cases where the URL will still be displayed, but I imagine they should be rare.

Overall I think the names look cleaner, so 👍 from me.

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 21, 2021

📌 Commit b7135644b3a39db3477927e9cd4cb249c9f2e963 has been approved by ehuss

@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 Jul 21, 2021
@bors
Copy link
Collaborator

bors commented Jul 21, 2021

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout issue-6691 (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self issue-6691 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging tests/testsuite/registry.rs
Auto-merging tests/testsuite/publish_lockfile.rs
Auto-merging tests/testsuite/patch.rs
Auto-merging tests/testsuite/offline.rs
Auto-merging tests/testsuite/install.rs
Auto-merging tests/testsuite/directory.rs
CONFLICT (content): Merge conflict in tests/testsuite/directory.rs
Auto-merging tests/testsuite/build.rs
Auto-merging tests/testsuite/bad_config.rs
Auto-merging src/cargo/ops/registry.rs
Automatic merge failed; fix conflicts and then commit the result.

@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 Jul 21, 2021
@ehuss
Copy link
Contributor

ehuss commented Jul 21, 2021

Oops, didn't see the conflicting file. Can you rebase?

@bors r-

This fixes most messages to display registry names instead of URLs.
Since current lockfile does not serialize any registry names. We here
try best effort to restore registry name from either `[registries]`
table or `[source]` replacement table. This is done by manually
implementing `Hash` and `PartialEq` for `SourceIdInner`, of which two
traits previously are simply `derive`d.

To make `SourceIdInner` generate the same hash whether contains `name`
field or not, here we remove `name` field from hashing and only concern
about `kind`, `precise` and `canonical_url`.
@weihanglo
Copy link
Member Author

Rebased. Thanks for your review @ehuss 😄

@ehuss
Copy link
Contributor

ehuss commented Jul 21, 2021

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 21, 2021

📌 Commit 8c75e2f has been approved by ehuss

@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-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Jul 21, 2021
@bors
Copy link
Collaborator

bors commented Jul 21, 2021

⌛ Testing commit 8c75e2f with merge 706c291...

@bors
Copy link
Collaborator

bors commented Jul 21, 2021

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

@bors bors merged commit 706c291 into rust-lang:master Jul 21, 2021
@weihanglo weihanglo deleted the issue-6691 branch July 22, 2021 01:24
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 22, 2021
Update cargo

2 commits in 4e143fd131e0c16cefd008456e974236ca54e62e..cebef2951ee69617852844894164b54ed478a7da
2021-07-20 21:55:45 +0000 to 2021-07-22 13:01:52 +0000
- Changes rustc argument from `--force-warns` to `--force-warn` (rust-lang/cargo#9714)
- Display registry name instead of registry URL when possible (rust-lang/cargo#9632)
@ehuss ehuss added this to the 1.55.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using alternative registries names in text output
6 participants