-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Alternative registry references are inconsistent between the name and index URL #4880
Comments
The two options are: All URLs
All names
The "all names" approach seems a bit cleaner, and I think matches better with what @withoutboats's idea of registry identification is. |
@sfackler can you remind me the motivation for rewriting manifests as publish? Is that required today for correctness? Or is that just required when you run |
Right yeah. In current Cargo, we rewrite manifests to support older Cargos, I think specifically with older TOML parsers. For example, the object shorthand |
Oh actually that's wrong. It already strips path keys from dependency objects. It was implemented in #4030. |
Oh so we don't actually do it to support older cargos, the original motivation was to support the use case of I suppose I should answer my own question though. So let's say we don't do anything other than what we do today. That way when you run Since vendoring requires a ... hm... So is the desire to be more consistent here one that fixes a bug? Or is it just 'we should be consistent'? |
I think this is an instance of a more core issue that we should decide: what does a registry name represent? In one way of thinking about it, a registry name is just a local alias that you as a developer use to not have to stick a big long git URL in every dependency you're pulling from a custom registry. The name itself doesn't have any meaning, and I can choose a different name than you do. In this world, we need to make sure the packages you publish either rewrite the name you chose to the index URL it represents, or to include the name to index mapping information in the package. In the other way of thinking about it, a registry has a single canonical name. We never refer to the URL at when publishing, either in the metadata or package tarball itself. @withoutboats prefers this world since it allows you to move a registry from one URL to another without needing to rewrite every index that references its packages, but instead just require users to update their local mappings. We currently have the worst of both worlds, where there's a canonical URL and a canonical name that everyone needs to agree on. |
As @sfackler has suggested, my preference is to use all names and require end users to map those names to index URLs. These are the reasons:
|
Hm ok, but so hang on I'd just like to confirm one thing first. We don't actually have a technical problem today, right? If I have a registry at registry.alexcrichton.com, you can call it foo, publish a crate to it, and then I can call it bar, and I can use your crate, right? Assuming that works (which I think it does), here's my thoughts! While it's true that two developers can give a different name to the same registry, I sort of doubt this will ever happen in practice. That, for example, means that I can't work on any of your packages without extra configuration (or vice versa). There's sort of a carrot to name everything the same because that way you don't have to maintain a list of all registry names for one URL. So I think yes, effectively in practice, if we have names then we have a unique (ish) name per registry. Now one thing I don't like about custom names though is that it's possible to have two disjoint communities that both name their registry I'd still sort of personally lean on the status quo, with names in manifests that you write down in For things like mirrors and whatnot I think we'll still be covered. If we use a global name we could redirect the url for that name, but if we have a global url I think it'd work the same way internally in Cargo. For example the crates.io registry url isn't changing any time soon but we still want mirrors for that! So overall I think I'm on the side of:
|
Not if my crate depends on any other crates in that registry, because the Cargo.toml in the package I published would have |
@sfackler did this break in practice for you? I'm under the impression that when Cargo loads dependency information from registries it completely ignores the |
Yes
|
Hm ok, good to know and thanks for the example! If it's ok I'd like to dig into what's going on there tomorrow, that's not behaving like I might expect. |
Sure. |
Looks like it's this part of the RFC that's not working quite right:
@sfackler's registry currently has: {
"name": "my-crate2",
"vers": "0.1.0",
"deps": [
{
"name": "my-crate",
"req": "^0.1",
"features": [
],
"optional": false,
"default_features": true,
"target": null,
"kind": "normal"
}
],
"cksum": "4c2ca7b247a9865c0d2239e963f196b872e234a143619581c07c157ab7afcea7",
"features": {
},
"yanked": false
} Because my-crate doesn't have a registry specified, cargo should assume it can find my-crate in the same registry that my-crate2 is. It might actually be doing that, but this error:
is happening way before then, and requiring that every registry name in every dependency's Cargo.toml have a corresponding index in a .cargo/config somewhere, even if it's not needed? That's my current understanding of the problem... |
Cargo's dependency resolution logic does handle this situation correctly - I don't think it's possible for Cargo to totally ignore the packaged Cargo.toml - the |
Ok I see what's going on here, and I believe this is a bug! What's happening is that Cargo during Parsing the manifest is failing here because Cargo's trying to construct a [dependencies]
my-crate = { version = "0.1", registry = "foo" } When parsing this we hit this case which notably calls Now this failure isn't actually useful here because the So for this specifically (without changing much else) there's two possible fixes:
That's to say at least that I don't think this is a slam dunk in any direction of how to fix this and what we should canonicalize on. |
Elaborating to registry-index seems a bit cleaner, and also helps maintain the aim of #4030 to keep published crates buildable directly. I'll make a PR and we can discuss it there. |
@sfackler I agree! |
This avoids introducing a dependency on the publisher's name for the registry. Closes rust-lang#4880
Elaborate registry names to index URLs when publishing This avoids introducing a dependency on the publisher's name for the registry. Closes #4880
Dependency information in
Cargo.toml
refers to alternative registries by their name, while the dependency information in the index JSON refers to alternative registries by URL. We should consistently use one or the other.@withoutboats
The text was updated successfully, but these errors were encountered: