rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.58k stars 2.38k forks source link

Support depending on crates with any case of the original name #5678

Open carols10cents opened 6 years ago

carols10cents commented 6 years ago

Similarly to https://github.com/rust-lang/cargo/issues/2775, because we consider a crate name to be unique no matter what the casing of the name, we should look up crates in the index regardless of whether the casing in a Cargo.toml matches the casing in the index exactly.

The directory and file names in the index are already all lowercase.

alexcrichton commented 6 years ago

I think this may already happen?

carols10cents commented 6 years ago

If I make a Cargo.toml with:

[dependencies]
LIBC = "*"

and then cargo build, I get:

error: no matching package named `LIBC` found
alexcrichton commented 6 years ago

Ah ok, that's a different issue then what's in the title!

carols10cents commented 6 years ago

o.O how so? when depending on a crate, doesn't that look up the crate in the index?

alexcrichton commented 6 years ago

Crate name comparison happens a few places in Cargo. Cargo already case-insensitively looks up the crate in the registry, but the name is later rejected due to the wrong case. It's elsewhere in Cargo's crate graph resolver that the case mapping would need to happen I believe.

jasonwilliams commented 5 years ago

@alexcrichton @carols10cents hey Is there any update to this? I have a crate in Cargo which has a capital letter and i would like to change it

vcfxb commented 4 years ago

I am also waiting on an update to this

epage commented 10 months ago

I feel like having something besides the canonical name in Cargo.toml will make it harder for users and tooling to process Cargo.toml files. I'm going to propose to the cargo team that we close this.

jasonwilliams commented 10 months ago

@epage I don’t understand what you mean or how it’s related to this issue. What is making it harder for tooling to process cargo.toml files?

epage commented 10 months ago

If a dependency name can come in any case (or use of _ vs -), then finding the canonical version becomes more complex.

Eh2406 commented 10 months ago

Knowing how to canonicalize a name is already required for looking it up in the index. So how much more difficult would this really make things? I.E. I don't think progress will be easy or likely, but am not yet convinced that we should close the discussion.

epage commented 10 months ago

Looking up in the index requires normalization which is slightly different than canonicalization and a lot of tools don't need to talk to the index and of those that do, it is behind an abstraction like tame-index.

Maybe put another way: right now, tools can just compare keys (or package fields) and are done. We centralize some canonicalization within cargo add and I can see doing more. By allowing non-canonical package names / dependency names, we shift that central logic in cargo add to every tool, requiring a lot of updates and I can very easily see that being filled with bugs. For example, to correctly check if workspace inheritance is in use, people will either need a newtype for the keys that can correctly hash or sort the canonicalization rules (easy to get right if you take the cost of creating a new string, easy to get if you try to do it in-place) or they'll have to walk every key, doing the check.

jasonwilliams commented 10 months ago

Ok I've just seen you now warn about case-sensitive crate names when created. I do think the warning should say the "case can't be changed once its submitted" but it's better than nothing.

I'm content with this, as long as users are aware of this issue when submitting new crates. I guess nothing can be done for existing crates.