Http registry #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…richton
Normalize SourceID in `cargo metadata`.
The SourceID in `cargo metadata` can have different values, but they can be equivalent in Cargo. This results in different serialized forms, which prevents comparing the ID strings. In this particular case, `SourceKind::Git(GitReference::Branch("master"))` is equivalent to `SourceKind::Git(GitReference::DefaultBranch)`, but they serialize differently.
The reason these end up differently is because the `SourceId` for a `Package` is created from the `Dependency` declaration. But the `SourceId` in `Cargo.lock` comes from the deserialized file. If you have an explicit `branch = "master"` in the dependency, then versions prior to 1.47 would *not* include `?branch=master` in `Cargo.lock`. However, since 1.47, internally Cargo will use `GitReference::Branch("master")`.
Conversely, if you have a new `Cargo.lock` (with `?branch=master`), and then *remove* the explicit `branch="master"` from `Cargo.toml`, you'll end up with another mismatch in `cargo metadata`.
The solution here is to use the variant from the `Package` when serializing the resolver in `cargo metadata`. I chose this since the `Package` variant is displayed on other JSON messages (like artifact messages), and I think this is the only place that the resolver variants are exposed (other than `Cargo.lock` itself).
I'm not convinced that this was entirely intended, since there is [code to avoid this](https://github.com/rust-lang/cargo/blob/6a38927551df9bbe2dea340bf92d3e53abccf890/src/cargo/core/resolver/encode.rs#L688-L695), and at the time rust-lang#8522 landed, I did not realize this would change the V2 lock format. However, it's probably too late to try to reverse that, and I don't think there are any other problems other than this `cargo metadata` inconsistency.
Fixes rust-lang#8756
This will keep `crates-io` compiling if rust-lang/rust#33953 is fixed. See dtolnay/anyhow#120
Bump `anyhow` dependency to `1.0.34` in `crates-io` crate This will keep `crates-io` compiling if rust-lang/rust#33953 is fixed. See dtolnay/anyhow#120
fix: remove install command `$`, for copying friendly
Avoid some extra downloads with new feature resolver. There are some edge cases with the new feature resolver where it can erroneously trigger a download of a package that is not needed. This is due to the call `is_proc_macro` which has to downloaded the manifest to check if it is a proc-macro. The main change here is to defer calling `is_proc_macro` until after dependencies have been filtered. It also avoids calling `is_proc_macro` if the new feature resolver is enabled, but `decouple_host_deps` and `ignore_inactive_targets` are disabled (such as with `-Z weak-dep-features`), in which case it doesn't matter if it is a proc-macro or not. Fixes rust-lang#8776
This consistently puts for_host next to PackageId, since the pair PackageId/for_host is used everywhere together. Somehow it seems better to me to consistently keep them close together.
Implement weak dependency features. This adds the feature syntax `dep_name?/feat_name` with a `?` to only enable `feat_name` if the optional dependency `dep_name` is enabled through some other means. See `unstable.md` for documentation. This only works with the new feature resolver. I don't think I understand the dependency resolver well enough to implement it there. It would require teaching it to defer activating a feature, but due to the backtracking nature, I don't really know how to accomplish that. I don't think it matters, the main drawback is that the dependency resolver will be slightly more constrained, but in practice I doubt it will ever matter. Closes rust-lang#3494 **Question** * An alternate syntax I considered was `dep_name?feat_name` (without the slash), what do people think? For some reason the `?/` seems kinda awkward to me.
anyhow::Error always captures a backtrace when created, which is expensive
This fixes the case where a package contained an empty .cargo-ok file and was mounted in a read only file system. This lead to attempting to download the package again, which failed due to write permissions.
Both are similar to rustc-cdylib-link-arg. The rustc-bin-link-arg option adds -C link-arg=... on binary targets. The rustc-link-arg option adds -C link-arg=... on all supported targets (currently only binaries and cdylib libraries).
This hides the new rustc-bin-link-arg and rustc-link-arg build script configuration items behind an unstable flag.
…r=Eh2406 Clarify cargo manifest edition field docs addresses rust-lang#8951 This PR aims to clarify the documentation for the `edition` field in the Cargo manifest. The confusion (IME) stems from the behavior of `cargo new` (defaults to writing edition = "2018") being confused for the default behavior of how Cargo interprets the manifest (`edition` is an optional key, defaults to 2015). would love to get some other thoughts on how we can clarify this since it seems like I'm not the only one who got confused `@Eh2406`
Change it so that if both are specified, it is an error just to be safer for now. If token is specified for a registry, ignore the global credential-process. I'm still uncertain if this is the best behavior, but I think we can tweak it later if needed.
The rust-lang/rust build infrastructure uses a version of Linux that is too old to support building this.
This reverts commit 85b5b18.
This reverts commit eadb4fc.
This commit fixes rust-lang#8966 by updating the unit generation logic to avoid generating an erroneous circular dependency between the execution of two build scripts. This has been present for Cargo in a long time since rust-lang#5651 (an accidental regression), but the situation appears rare enough that we didn't get to it until now! Closes rust-lang#8966
Fix the unit dependency graph with dev-dependency `links` This commit fixes rust-lang#8966 by updating the unit generation logic to avoid generating an erroneous circular dependency between the execution of two build scripts. This has been present for Cargo in a long time since rust-lang#5651 (an accidental regression), but the situation appears rare enough that we didn't get to it until now! Closes rust-lang#8966
Revert recent build-std vendoring changes This reverts rust-lang#8834 to address rust-lang#8962 and rust-lang#8963 cc `@Gankra`
Implement external credential process. (RFC 2730) This adds a config setting for an external process to run to fetch the token for a registry. See `unstable.md` for more details. As part of this, it adds a new `logout` command. This is currently gated on nightly with the appropriate `-Z` flag. I have included four sample wrappers that integrate with the macOS Keychain, Windows Credential Manager, GNOME libsecret, and 1password. I'm not sure if we'll ultimately ship these, but I would like to. Primarily this provided a proof-of-concept to see if the design works. **Patch Walkthrough** This is a brief overview of the changes: - Adds the `logout` command. With `cargo logout -Z unstable-options`, this allows removing the `token` from `.cargo/credentials`. With `cargo logout -Z credential-process`, this launches the process with the `erase` argument to remove the token from storage. - Credential-process handling is in the `ops/registry/auth.rs` module. I think it is pretty straightforward, it just launches the process with the appropriate store/get/erase argument. - `ops::registry::registry()` now returns the `RegistryConfig` to make it easier to pass the config information around. - `crates/credential/cargo-credential` is a helper crate for writing credential processes. - A special shorthand of the `cargo:` prefix for a credential process will launch the named process from the `libexec` directory in the sysroot (or, more specifically, the `libexec` directory next to the `cargo` process). For example `credential-process = "cargo:macos-keychain"`. My intent is to bundle these in the pre-built rust-lang distributions, and this should "just work" when used with rustup. I'm not sure how that will work with other Rust distributions, but I'm guessing they can figure it out. This should make it much easier for users to get started, but does add some integration complexity. **Questions** - I'm on the fence about the name `credential-process` vs `credentials-process`, which sounds more natural? (Or something else?) - I'm uneasy about the behavior when both `token` and `credential-process` is specified (see `warn_both_token_and_process` test). Currently it issues a warning and uses `token`. Does that make sense? What about the case where you have `registries.foo.token` for a specific registry, but then have a general `registry.credential-process` for the default (it currently warns and uses the token, maybe it should not warn?)? - I am still pretty uneasy with writing FFI wrappers, so maybe those could get a little extra scrutiny? They seem to work, but I have not extensively tested them (I tried login, publish, and logout). I have not previously used these APIs, so I am not familiar with them. - Testing the wrappers I think will be quite difficult, because some require TTY interaction (and 1password requires an online account). Or, for example in the macOS case, it has GUI dialog box where I can use my fingerprint scanner. Right now, I just build them in CI to make sure they compile. - 1password is a little weird in that it passes the token on the command-line, which is not very secure on some systems (other processes can see these sometimes). The only alternative I can think of is to not support `cargo login` and require the user to manually enter the token in the 1password GUI. I don't think the concern is too large (1password themselves seem to think it is acceptable). Should this be OK? - I'm a little uneasy with the design of `cargo login`, where it passes the token in stdin. If the wrapper requires stdin for user interaction (such as entering a password to unlock), this is quite awkward. There is a hack in the 1password example that demonstrates using `/dev/tty` and `CONIN$`, which *seems* to work, but I'm worried is fragile. I'm not very comfortable passing the token in environment variables, because those can be visible to other processes (like CLI args), but in some situations that shouldn't be too risky. Another option is to use a separate file descriptor/handle to pass the token in. Implementing that in Rust in a cross-platform way is not terribly easy, so I wanted to open this up for discussion first.
Check if rerun-if-changed points to a directory. This changes it so that if a build script emits `cargo:rerun-if-changed` pointing to a directory, then Cargo will scan the entire directory for changes (instead of just looking at the mtime of the directory itself). I think this is more useful, as otherwise build scripts have to recreate this logic. I've tried to make it semi-intelligent in the face of symbolic links. It checks the mtime of the link and its target, and follows the link if it points to a directory. There are a few other edge cases. For example, if it doesn't have permission for a directory, it will skip it. I think this is relatively reasonable, though it's hard to say for sure.
This also re-enables the requirement of -Z http-registry
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.