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

Track which commands a registry supports in its config.json #4747

Closed
wants to merge 3 commits into from

Conversation

withoutboats
Copy link
Contributor

@withoutboats withoutboats commented Nov 24, 2017

This arose out of #4574. The idea is for cargo to only perform an action if the registry supports that command.

The 5 existing commands that interact with registries are:

  1. publish
  2. yank
  3. owner
  4. search
  5. login (technically never makes a direct request, but is clearly an interaction with the registry semantically)

This proposes to track each command as an array of supported versions:

{
    "api": "https://crates.io/",
    "dl": "https://crates.io/api/v1/crates",
    "commands": {
        "publish": ["v1"],
        "yank": ["v1"],
        "owner": ["v1"],
        "search": ["v1"],
        "login": ["v1"]
    }
}

(On the issue it was discussed having an "api" string for each command, but the actual APIs of the commands are not conducive to this because parts of the query are in the path.)

Before merging, this commands object would need to be added to the config.json of the crates.io index.

@cswindle @carols10cents @rust-lang/cargo

Without Boats added 2 commits November 17, 2017 20:56
The registry config.json contains an extra field, "commands",
an object. The fields of this object each is a command, which
records which versions (if any) of this command that registry
supports. A complete registry, as of today, would have these
commands:

```json
{
    "login": ["v1"],
    "publish": ["v1"],
    "owner": ["v1"],
    "search": ["v1"],
    "yank": ["v1"]
}
```
Prior to this commit, the login flow for registries other than the
default does not support the token pasting flow. Now, if the host
flag is specified, or the registry claims to support the "v1" flow,
we enter the token pasting flow.
@rust-highfive
Copy link

r? @alexcrichton

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

@withoutboats withoutboats added the A-registries Area: registries label Nov 24, 2017
@alexcrichton
Copy link
Member

This seems reasonable to me! (although I haven't really spent much time thinking through ramifications. I think merging of this would need to be preceded with a change to the actual index, right?

@withoutboats
Copy link
Contributor Author

I think merging of this would need to be preceded with a change to the actual index, right?

Correct

@withoutboats
Copy link
Contributor Author

Can't replicate the test failure locally :-\

@alexcrichton
Copy link
Member

Hm using the latest stable locally on a fresh checkout if I do

$ cargo test --test lockfile-compat frozen
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/lockfile_compat-7dabde45d28ef23c

running 1 test
test frozen_flag_preserves_old_lockfile ... FAILED

failures:

---- frozen_flag_preserves_old_lockfile stdout ----
        running `/home/alex/code/cargo/target/debug/cargo build --locked`
thread 'frozen_flag_preserves_old_lockfile' panicked at '
Expected: execs
    but: exited with exit code: 101
--- stdout

--- stderr
    Updating registry `file:///home/alex/code/cargo/target/cit/t0/registry`
error: checksum for `foo v0.1.0` changed between lock files

this could be indicative of a few possible errors:

    * the lock file is corrupt
    * a replacement source in use (e.g. a mirror) returned a different checksum
    * the source itself may be corrupt in one way or another

unable to verify that `foo v0.1.0` is the same as when the lockfile was generated

', /home/alex/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/hamcrest-0.1.1/src/core.rs:31:12
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    frozen_flag_preserves_old_lockfile

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 8 filtered out

@matklad mind helping take a look at this failure (it's on master, not just with this PR)

@bors
Copy link
Contributor

bors commented Dec 19, 2017

☔ The latest upstream changes (presumably #4836) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

This has been inactive for some time now so I'm going to close this, but it can of course be resubmitted!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-registries Area: registries
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants