-
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
Add support for publish to optionally take the index that can be used #4568
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matklad (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
☔ The latest upstream changes (presumably #4559) made this pull request unmergeable. Please resolve the merge conflicts. |
Conflicts: src/cargo/core/package.rs
Looks great! I think I'd like to try to throw this in with #4506 though as we'll want to be sure to feature gate the acceptance of a list of strings here I believe (and the feature gate bits were added in that PR) |
It looks like #4506 is getting close to merge, so maybe that should be merged, then I will add in feature gating to this PR when I merge the changes in. |
Ok sure yeah, either way's fine by me |
I think we should probably merge #4506 separately. I have some big picture concerns about how we're handling publishing in general, which we're talking about on #4574, but also these smaller concerns: I think this list should take registry names (as will be introduced in #4506), not index URLs, as @cswindle mentioned doing in the first comment. In general we're moving away from users dealing with index URLs as much as possible. There's also the issue with passing |
I am fine switching to registry names, I will sort that out once your stuff is merged. Regarding not pushing the token to an alternate registry, maybe it would be better just blocking sending the token if --index is provided (as that is the only way to send to an alternate registry) and instead --token must be provided in that situation. That sounds like it would offer protection from tokens being accidentally sent to the wrong server (until there is support for multiple registry tokens). |
In the case of providing a registry that we want to use in publish, I actually wonder if we should just make a minor tweak to registry_configuration to pass in the registry (if provided) and look up the "registry.<registry>.token" in the config, otherwise just get "registry.token". That way we can cross off the issue to support multiple registry tokens. |
@cswindle ah yeah it was my expectation that |
@alexcrichton I presume that is not something that would need to be done in an rfc and could just be implemented as part of this pull request (assuming resolution of #4574 is that we want to be able to push to private registries). |
@cswindle indeed yeah! |
☔ The latest upstream changes (presumably #4506) made this pull request unmergeable. Please resolve the merge conflicts. |
Conflicts: src/cargo/util/toml/mod.rs
Looks great! For now as well, could this be gated on the same alternate registries feature in the manifest? |
@alexcrichton, now that the alternate registries has landed I was planning on updating this to be gated on the feature in the manifest. I have been taking a look into adding support for --registry for publish and login and if that is available it actually makes the code to perform the registry lookup easier (assuming that it is ok to mandate that if you want to push to alternate registry you use --registry rather than --index), so I might try and get that in first. |
@cswindle ok sounds great! I think with a |
See #4680 for the PR to add --registry support. |
I have now merged in my changes to add support for this. I am aware of the following two issues from further testing of this:
I am in the process of sorting these last couple of bits out, so think it would make sense to do so in this pull request, rather than having another to do the last couple of bits. |
I believe that this should now allow publishing and can be reviewed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great, thanks!
src/cargo/ops/registry.rs
Outdated
bail!("some crates cannot be published.\n\ | ||
`{}` is marked as unpublishable", pkg.name()); | ||
if let &Some(ref allowed_registries) = pkg.publish() { | ||
if opts.registry.is_none() || !allowed_registries.contains(&opts.registry.clone().unwrap()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this could be:
if let Some(ref registry) = opts.registry {
if !allowed_registries.contains(registry) {
bail!(...);
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work as if there are allowed registries setup, but we have not provided --registry then we also need to block. This covers the case of pushing to crates.io when publish is set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Er so what I mostly mean here is getting rid of the is_none
+ clone
+ unwrap
, basically restructuring this to avoid all the function calls (and make it a little easier to read)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have got rid of the is_none, unwrap etc.
src/cargo/core/source/source_id.rs
Outdated
@@ -44,6 +44,8 @@ enum Kind { | |||
Path, | |||
/// represents a remote registry | |||
Registry, | |||
/// represents a remote alternative registry | |||
AltRegistry, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd ideally like to avoid having a separate source for alternative registries here, would it be possible to just use Registry
above and recognize crates.io through an identifier like "crates-io"? Either that or perhaps a method like is_default_registry(&self) -> bool
or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that in order to distinguish if it is the default registry in unit tests it becomes more of a pain as we can't purely check for if the index matches crates.io index. One change that I made as part of #4697 was to store the name in the source_id, that would then allow just checking if that was present, rather than there being an additional type, would you prefer that approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this to use the name as that also fixed the bug that you highlighted.
src/cargo/ops/registry.rs
Outdated
bail!("crates cannot be published to crates.io with dependencies sourced from other\n\ | ||
registries either publish `{}` on crates.io or pull it into this repository\n\ | ||
and specify it with a path and version\n\ | ||
(crate `{}` is pulled from {}", dep.name(), dep.name(), dep.source_id()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you're at it I think there's a missing )
in this message, mind throwing it in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will make that change.
src/cargo/util/toml/mod.rs
Outdated
Some(vecstring.clone()) | ||
}, | ||
Some(VecStringOrBool::Bool(false)) => Some(vec![]), | ||
_ => None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this explicitly match None
and Some(Bool(true))
just to be exhaustive?
tests/alt-registry.rs
Outdated
@@ -65,11 +65,13 @@ fn depend_on_alt_registry() { | |||
// Don't download a second time | |||
assert_that(p.cargo("build").masquerade_as_nightly_cargo(), | |||
execs().with_status(0).with_stderr(&format!("\ | |||
[UPDATING] registry `{reg}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm this looks like a bug? I don't think that an update should happen here for a clean build?
tests/alt-registry.rs
Outdated
@@ -91,7 +93,7 @@ fn depend_on_alt_registry_depends_on_same_registry() { | |||
.build(); | |||
|
|||
Package::new("baz", "0.0.1").alternative(true).publish(); | |||
Package::new("bar", "0.0.1").registry_dep("baz", "0.0.1", registry::alt_registry().as_str()).alternative(true).publish(); | |||
Package::new("bar", "0.0.1").dep("baz", "0.0.1").alternative(true).publish(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm how come this change was required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is required as using registry_dep includes the registry in the dependencies, but for when a crate is published to the same registry it should not include the registry in the dependencies (otherwise it makes it a lot more difficult to move the index).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh hm, this I thought was an explicit decision where an omitted key implies "crates.io" and an explicit key is required for any other registry. @withoutboats want to confirm though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcrichton, I did this way due to the following in the RFC:
If a dependency's registry is not specified, Cargo will assume the dependency can be located in the current registry. By specifying the registry of a dependency in the index, cargo will have the information it needs to fetch crate files from the registry indices involved without needing to involve an API server.
However, as this is optional, I will add an additional test to cover both when we do and don't have a registry set in the index.
assert_that(p.cargo("publish").masquerade_as_nightly_cargo() | ||
.arg("--index").arg(registry::alt_registry().to_string()), | ||
execs().with_status(101)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this perhaps stick around as a separate test? I think we'll want an assertion that you can't publish a crate with dependencies on a separate registry to crates.io
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added the test back.
@alexcrichton, I have updated the code for most of the review comments, there are a couple where I have not updated, but in those cases I have explained why in the comments. |
I think you'll want to take a final pass here |
@bors: r+ Sorry to take a while to review. This all looks good to me, no further changes. needed :) |
📌 Commit cb37d33 has been approved by |
Add support for publish to optionally take the index that can be used This form part of alternative-registries RFC-2141, it allows crates to optionally specify which registries the crate can be be published to. @carols10cents, one thing that I am unsure about is if there is a plan for publish to still provide index, or for registry to be provided instead. I thought that your general view was that we should move away from the index file. If we do need to map allowed registries to the index then there will be a small amount of extra work required once #4506 is merged. @withoutboats, happy for this to be merged into your branch if you want, the main reason I did not base it on your branch was due to tests not working on there yet.
☀️ Test successful - status-appveyor, status-travis |
This form part of alternative-registries RFC-2141, it allows crates to optionally specify which registries the crate can be be published to.
@carols10cents, one thing that I am unsure about is if there is a plan for publish to still provide index, or for registry to be provided instead. I thought that your general view was that we should move away from the index file. If we do need to map allowed registries to the index then there will be a small amount of extra work required once #4506 is merged.
@withoutboats, happy for this to be merged into your branch if you want, the main reason I did not base it on your branch was due to tests not working on there yet.