-
Notifications
You must be signed in to change notification settings - Fork 18
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
Be able to host & use private crate registries #10
Comments
Closing this as Cargo has the support now and there is at least a first private cloud hosted crate registry with Cloudsmith: https://blog.cloudsmith.io/2019/05/01/worlds-first-private-cargo-registry/ |
Reopened this because I tested out the alternate registry support together with cloudsmith and unfortunately Cargo doesn't support the main use case we have. What we would like to do is to have a mechanism to privately publish individual crates that we have, that are in development, to a private registry and reference them in other private crates and repos. [dependencies]
embark-test = { version = "0.2.0", registry = "embark" } And this itself does work, but only if the crate doesn't have any dependencies itself or if it only have dependencies that are in the same private registry and they are not also used from The first issue here for us is that all transitive dependencies of the crate from the private registry also have to exist in the private registry, so if say What we are actually after in our use case is that we just want to publish our private crates in our private registry, and use everything that doesn't specify There doesn't seem to be a way to do this today and I'm unsure how we should proceed |
@repi Lee from @cloudsmith-io here! This popped up on my radar, so thought I'd offer some assistance. We recently made a change that would help alleviate at least the first problem. Enabling "Use crates.io as default Cargo upstream?" in your repository settings would allow for transitive dependencies to exist on Don't forget, we're always happy to help out if you're having issues. Sometimes it's possible that we need to make some changes on our side to improve your quality of life, but that's why we're there. :-) |
@lskillen oh that is super interesting and relevant, will try it out and see if it solves our use case. big thanks for reaching out! |
Not a problem! If it doesn't, let me know and we'll sort it out for you. 😊 |
Tested it now and just checking that "Use crates.io as default Cargo upstream" checkbox worked perfectly for us and resolves our issues! It picks up the private crate that we have uploaded and specified that it should use the private registry, and all its dependencies (including transitive) gets picked up by crates.io and there is no duplication of crates or issues. Sweet! Did run into a minor potential issue with Cargo in that its log output writes out the full URL for the registry instead of the name of the registry. And in the cloudsmith case this can include the secret entitlement token for it which unnecessarily leaks it into log files and such.
Think it would be cleaner, nicer, and safer it Cargo just writes out the name of the registry here instead of the URL for it. Should be an easy fix in Cargo and found an issue for it here: |
@repi You're absolutely right; we've put our thumbs up on that as well. 👍 In the meantime, it's possible to get around this by configuring basic authentication instead of using entitlement tokens; where the former is authentication via a header, and the latter bakes the token into the URI itself. Screenshot for configuration (accessed via "Set Me Up" from the top-right): As Cargo is built upon the git protocol, it requires the credentials to be registered with git, using the credentials store. Quick example (from our own examples):
In this case we're using an API key, and Configuring this means that your credentials won't be baked into any output or logs. |
Cool thanks, may try out that approach also |
We're implementing our own private registry at TenX. I encountered this case as well, but then I realized I was doing it wrong. With each dependency, the index is supposed to store the // The URL of the index of the registry where this dependency is
// from as a string. If not specified or null, it is assumed the
// dependency is in the current registry.
"registry": null, That explains really well. So I added this to my index and it worked.
Since the first issue does not exist, the second issue will not arise in the first place,
We're doing exactly this. So far we're able to do that, though we've not deployed our registry to production, but I'm hoping it's going to work. |
Is https://github.com/cswindle/caesium the only open source private registry? |
@gilescope (and for other coming here) you also have https://github.com/Hirevo/alexandrie |
@gilescope There is also this one https://github.com/mcorbin/meuse (I have not tried using it yet myself). |
I’ve been making good progress with using cargo-local-registry and using a non-rust package manager to provision the crates there. Sent with GitHawk |
We're interested in being able to do a local instance of docs.rs and point it to or private crate registry as well, filed a separate issue on that in #47 |
Closing this as the last Rust issue around CLI output was fixed a while back rust-lang/cargo#6691, we've had no problems at all with Cloudsmith as a private crate registry either, it is great |
This used to be important for us as we have a lot of private crates and dependencies between them.
But we have since moved to a monorepo for all of our Rust crates where it is easy to set up dependencies within the repository and workspace.
But believe for other companies this will be critical to adopt Rust.
One workaround that we've used in the past when having multiple private repositories of crates with dependencies between them is to set up the dependencies as git dependencies. The draw back of that is that it is both slower to download and more to set up on local machines and esp. CI.
The text was updated successfully, but these errors were encountered: