alternative registry support #336
Conversation
There was a problem hiding this comment.
First of all, thank you for the PR and sorry for the delay in response!
I've not added tests that actually query an alternative registry, because the tests currently rely on the user's cargo config.
It actually emulates what cargo does and starts with manifest_path/../.cargo/config, so we could create a test dir with a non-default config and use something like https://github.com/ordian/crates.io-index for an alternative registry.
Please rebase on master as well.
cargo-add gains a new registry flag. cargo-upgrade gets any alternative registry URLs from cargo metadata.
|
Thanks for the review. I've rebased and added a test fixture that uses https://github.com/ordian/crates.io-index. I had a couple of issues relating to cargo config:
|
There was a problem hiding this comment.
Thank you for addressing the issues so quickly!
I hit #339,
Suggested a patch to resolve it.
The cargo config probing differs slightly between cargo and cargo-edit.
Hmm, this seems concerning. The ultimate fix is to merge cargo-edit with cargo. If you want to help with this, see this comment.
336: alternative registry support r=ordian a=tofay This PR adds support for alternative registries. The main change is updating the `fetch::get_latest_dependency` to optionally accept a registry URL. I'm using URLs not registry names, because `cargo metadata` returns the URL of the index whenever the dependency is being sourced from an alternative registry. When adding dependencies from alternative registries, the user specifies a registry name which is then converted to the relevant URL. For this purpose, the cargo config parsing code in `registry.rs` is updated to handle registries other than crates-io. W.r.t testing, I've only added tests for the CLI/toml-editing aspects. I've been successfully using `cargo upgrade` with my company's alternative registry, but I've not added tests that actually query an alternative registry, because the tests currently rely on the user's cargo config. Is that acceptable? (Cargo itself has private test fixtures for working with alternative registries - this could be reused when/if cargo-edit is moved into cargo.) Fixes #201 Fixes #339 Co-authored-by: Tom Fay <[email protected]>
This PR adds support for alternative registries.
The main change is updating the
fetch::get_latest_dependencyto optionally accept a registry URL. I'm using URLs not registry names, becausecargo metadatareturns the URL of the index whenever the dependency is being sourced from an alternative registry.When adding dependencies from alternative registries, the user specifies a registry name which is then converted to the relevant URL. For this purpose, the cargo config parsing code in
registry.rsis updated to handle registries other than crates-io.W.r.t testing, I've only added tests for the CLI/toml-editing aspects. I've been successfully using
cargo upgradewith my company's alternative registry, but I've not added tests that actually query an alternative registry, because the tests currently rely on the user's cargo config.Is that acceptable? (Cargo itself has private test fixtures for working with alternative registries - this could be reused when/if cargo-edit is moved into cargo.)
Fixes #201
Fixes #339