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

Add support for overriding download location for crates.io #6219

Open
cswindle opened this issue Oct 25, 2018 · 9 comments
Open

Add support for overriding download location for crates.io #6219

cswindle opened this issue Oct 25, 2018 · 9 comments
Labels
A-registries Area: registries S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@cswindle
Copy link
Contributor

Describe the problem you are trying to solve
I would like to setup a simple mirror of crates.io (including crates) for use within a company so that:

  • we are able to build our products in the future if there are any issues with crates.io
  • we have a local copy of all crates that we use to build our products

Describe the solution you'd like
For a mirror I would like to be able to override the download location for a registry so that it is possible to use something like artifactory to create a cache of all crates which are requested. I did originally propose a PR for this under #4697, which I managed to workaround the lack of support by modifying config.json to update the download location and then setup a job to perform the merges, however this is a pain as when there are merge conflicts merging the index it needs sorting before people using the mirror index can pick up the latest crates.

Having something along the following lines in cargo config would mean that a direct clone of the crates index file can be used in a mirror and thus reduce the overhead:

[source]

[source.mirror]
registry = "https://[host and path to your git server]/crates.io-index"
[source.mirror.config]
dl = <caching download location>

[source.crates-io]
replace-with = "mirror"

For completeness I would suggest allowing api as well to be overridden here (although in my scenario that is not required).

Notes

@cswindle
Copy link
Contributor Author

@sfackler, @withoutboats, I believe both of you may be interested in mirroring a registry and I would appreciate your views.

@cswindle
Copy link
Contributor Author

@sfackler, @withoutboats, any thoughts on this?

@sfackler
Copy link
Member

You can already do this via .cargo/config I believe:

[registry]
index = "https://my-custom-index.com"

https://doc.rust-lang.org/cargo/reference/config.html#configuration-keys

@cswindle
Copy link
Contributor Author

I am wanting to be able to override the download location from the config,json in the index as it is a pain needing to keep merging the crates.io index, rather than just doing a straight mirror of the repo.

@sfackler
Copy link
Member

Ah gotcha. That seems like a plausible feature as well I think.

@0Grit
Copy link

0Grit commented Jan 14, 2019

@cswindle Personally I'd like to be able override the download location for each dependency individually.

@alexcrichton
Initially I'm looking to use cargo purely for 'vendored' dependency & repository management.

cargo-vendor and source replacement in .cargo/config isn't cutting it for me.

@wt
Copy link

wt commented Feb 9, 2022

Is the workaround literally to vendor the crates.io registry and rebases a commit on top to change the config every time it's synced?

@wsgalaxy
Copy link

I want this feature too, we want a mirror for crates.io but every time we update the index, we need to merge to a modified branch.

@arlosi
Copy link
Contributor

arlosi commented Oct 7, 2022

We use automation that pulls from crates.io and applies a commit on top to modify the dl value. Since it applies on top of the latest commit from crates.io and just overwrites the contents of config.json, there are never any merge conflicts.

@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Oct 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-registries Area: registries S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

8 participants