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

fix(package): Recognize and normalize cargo.toml #12399

Merged
merged 6 commits into from
Jul 29, 2023
Merged

Conversation

epage
Copy link
Contributor

@epage epage commented Jul 24, 2023

What does this PR try to resolve?

This solution is a blend of conservative and easy

  • Normalizes cargo.toml to Cargo.toml on publish
    • Ensuring we publish the prepare_for_publish version and include Cargo.toml.orig
    • Avoids dealing with trying to push existing users to Cargo.toml
  • All other cases of Cargo.toml are warnings
    • We could either normalize or turn this into an error in the future
    • When helping users with case previously, we've only handle the cargo.toml case
    • We already should have a fallback in case a manifest isn't detected
    • I didn't want to put in too much effort to make the code more complicated to handle this

As a side effect, if a Linux user has cargo.toml and Cargo.toml, we'll only put one of them in the .crate file. We can extend this out to also include a warning for portability for case insensitive filesystems but I left that for after #12235.

How should we test and review this PR?

A PR at a time will show how the behavior changed as the source was edited

This does add a direct dependency on unicase to help keep case-insensitive comparisons easy / clear and to avoid riskier areas for bugs like writing an appropriate Hash implementation. unicase is an existing transitive dependency of cargo.

Additional information

Fixes #12384

Discussion on Zulip

@rustbot
Copy link
Collaborator

rustbot commented Jul 24, 2023

r? @weihanglo

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added Command-package S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2023
@epage epage force-pushed the normalize branch 2 times, most recently from 1d9fcb2 to 3166e5f Compare July 25, 2023 00:39
Copy link
Member

@weihanglo weihanglo left a comment

Choose a reason for hiding this comment

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

Another case this does not address (though slightly changes) is when a Linux system has multiple cases of Cargo.toml

Will this cause problems for projects already having both Cargo.toml and cargo.toml? Should we examine existing packages on crates.io?

Apart from that, looks pretty good!

To keep things simple, especially in getting a `Hash` implementation
correct, I'm leveraging `unicase` for case-insensitive
comparisons which is an existing dependency and I've been using for
years on other projects.

This also opens the door for us to add cross-platform compatibility
hazard warnings about multiple paths that would write to the same
location on a case insensitive file system.  I held off on that because
I assume we would want rust-lang#12235 first.

This does mean we can't test the "no manifest" case anymore because the
one case (no pun intended) I knew of for hitting it is now gone.
@epage
Copy link
Contributor Author

epage commented Jul 26, 2023

Will this cause problems for projects already having both Cargo.toml and cargo.toml? Should we examine existing packages on crates.io?

To lazy to examine them so I took an approach for handling it. Thoughts?

@ChrisDenton
Copy link
Contributor

Hm... unicase seems overkill no? IIRC, cargo's special filenames are all ascii.

@epage
Copy link
Contributor Author

epage commented Jul 26, 2023

Hm... unicase seems overkill no? IIRC, cargo's special filenames are all ascii.

I wrote this with an eye for portability hazards in the future. Unsure if filesystems are case insensitive by ascii or by unicode but thought I'd play it safe rather than people in the future building on the this work and not taking this into account.

@ChrisDenton
Copy link
Contributor

Sure but I mean, pure ascii filenames are the only ones that can be compared portably.

What version of the Unicode spec does a filesystem use to do case-insensitive comparisons? Trick question! It could be using any version or its own weird case table. So the only portable thing would be to ask the filesystem, unless you stick to ascii only.

@epage
Copy link
Contributor Author

epage commented Jul 26, 2023

@ChrisDenton to clarify, how much of your concern is with

  • unicase::UniCase
  • unicase as a dependency
  • any dependency for this

@ChrisDenton
Copy link
Contributor

ChrisDenton commented Jul 26, 2023

Well I do prefer having fewer dependencies but that's only a minor concern.

And I'm not against using unicase::UniCase exactly. It'll work for Cargo.toml, but then so would an ascii comparison. My concern is a bit more fundamental in that using any single case algorithm is wrong. With ascii comparisons the limitation is at least clear to the reader and the results correct within its domain.

The "correct" way to do this for arbitrary names outside of ascii is to try opening with the expected file name then comparing the canonical name of the opened file with the expected name. But I realise this might be more involved then is wanted here, especially considering cross-platform concerns.

@epage
Copy link
Contributor Author

epage commented Jul 26, 2023

Thanks for the clarification.

I've updated to ASCII comparisons. I kept unicase because it makes life easier in a couple of ways, in particular by choosing to use a HashMap, it makes it easy to get a correct Hash implementation. It is already a transitive dependency of cargo.

Copy link
Member

@weihanglo weihanglo left a comment

Choose a reason for hiding this comment

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

Looks good to me, and thanks everybody here for helping review :)

Comment on lines 2999 to 3006
[package]
name = "foo"
version = "0.0.1"
authors = []
exclude = ["*.txt"]
license = "MIT"
description = "foo"
"#,
Copy link
Member

Choose a reason for hiding this comment

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

nit: One less indentation?

@weihanglo
Copy link
Member

@bors r

@bors
Copy link
Collaborator

bors commented Jul 29, 2023

📌 Commit cc6b6c9 has been approved by weihanglo

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 Jul 29, 2023
@bors
Copy link
Collaborator

bors commented Jul 29, 2023

⌛ Testing commit cc6b6c9 with merge c863660...

@bors
Copy link
Collaborator

bors commented Jul 29, 2023

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing c863660 to master...

@bors bors merged commit c863660 into rust-lang:master Jul 29, 2023
21 checks passed
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 31, 2023
Update cargo

14 commits in 7ac9416d82cd4fc5e707c9ec3574d22dff6466e5..c91a693e7977e33a1064b63a5daf5fb689f01651
2023-07-24 14:29:38  0000 to 2023-07-31 00:26:46  0000
- fix: align `cargo --help` text (rust-lang/cargo#12418)
- fix: normalize relative git submodule urls with `ssh://` (rust-lang/cargo#12411)
- test: relax help text assertion (rust-lang/cargo#12416)
- test: relax assertions of panic handler message format (rust-lang/cargo#12413)
- fix(package): Recognize and normalize `cargo.toml` (rust-lang/cargo#12399)
- Clarify `lto` setting passing `-Clinker-plugin-lto` (rust-lang/cargo#12407)
- doc: add missing reference to `CARGO_PROFILE_<name>_STRIP` in environment variables docs (rust-lang/cargo#12408)
- Update curl-sys to pull in curl 8.2.1 (rust-lang/cargo#12406)
- docs: raise awareness of resolver used inside workspace (rust-lang/cargo#12388)
- chore: update `home` to 0.5.7 (rust-lang/cargo#12401)
- Update curl-sys to pull in curl 8.2.0 (rust-lang/cargo#12400)
- test(cli): Track --help output (rust-lang/cargo#11912)
- refactor(test): Move cargo-config into a dir (rust-lang/cargo#12398)
- refactor(tests): Name init ui tests more consistently (rust-lang/cargo#12397)

r? `@ghost`
@epage epage deleted the normalize branch August 4, 2023 17:43
@ehuss ehuss added this to the 1.73.0 milestone Aug 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Command-package 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.

cargo publish with cargo.toml on windows doesn't normalize the content
7 participants