-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Allow specifying alternate sources for dependencies #733
Comments
This is already possible with a local override in .cargo/config |
Interesting. Are local overrides documented somewhere? http://doc.crates.io/config.html doesn't seem to mention them. |
On that page,
http://doc.crates.io/guide.html#overriding-dependencies is said section 😄 |
Ah, thanks. I was expecting something more complicated (I didn't see any hashes mentioned, so my eyes just skipped past them). I'm a bit surprised the behavior here (override every dependency with the same name even if it refers to a different url/rev) is different from the behavior when a project with a dep on one version of a library (A) also depends on anther lib (B) that pulls another version of the library A (both versions are included in the build). Is this intentional? |
Yes, as @steveklabnik mentioned the method for doing this is overriding dependencies, and it's currently done via overriding package names. @jmesmon could you open a new bug about overrides perhaps being a bit too broad and maybe adding a system to hone precisely what's overridden? |
Thanks @jmesmon! |
@alexcrichton Is there a way of doing this, but for git dependencies? I've got a workspace that contains member crates. And several member crates have a dependency using a git url, however that dependency crate is also in my workspace, so I want to overwrite it with my local path without touching the member's Cargo.toml. And I don't want to override it inside the member, because that is valid if somebody clones that member alone.
|
When using a package manager that uses source code as the "package", we need to grab source at a different step than build.
Also, at times it's necessary to patch dependencies, which being able to point to a raw directory would allow.
I imagine we'd provide some mapping between "url#hash" and "directory".
One possibility would be to allow Cargo.lock to be edited to point to new locations/urls/hashes which don't match Cargo.toml without automatically re-updating it (and blowing away those changes).
The text was updated successfully, but these errors were encountered: