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

Allow specifying alternate sources for dependencies #733

Closed
codyps opened this issue Oct 21, 2014 · 8 comments
Closed

Allow specifying alternate sources for dependencies #733

codyps opened this issue Oct 21, 2014 · 8 comments

Comments

@codyps
Copy link
Contributor

codyps commented Oct 21, 2014

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).

@steveklabnik
Copy link
Member

This is already possible with a local override in .cargo/config

@codyps
Copy link
Contributor Author

codyps commented Oct 21, 2014

Interesting. Are local overrides documented somewhere? http://doc.crates.io/config.html doesn't seem to mention them.

@steveklabnik
Copy link
Member

On that page,

# An array of paths to local repositories which are to be used as overrides for
# dependencies. For more information see the Cargo Guide.
paths = [ "/path/to/override" ]

http://doc.crates.io/guide.html#overriding-dependencies

is said section 😄

@codyps
Copy link
Contributor Author

codyps commented Oct 21, 2014

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?

@alexcrichton
Copy link
Member

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?

@alexcrichton
Copy link
Member

Thanks @jmesmon!

@fxdave
Copy link

fxdave commented Jan 25, 2023

@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.

member/Cargo.toml <- this has the dependency as git url
common-lib/* <- this is the local version of that dependency
Cargo.toml <- I want to override it here to my local path

@weihanglo
Copy link
Member

Hello @fxdave, this issue is quite old and the approach here might not be what you want. Without any further detail, it sounds [patch] can help you get through it. I'd suggest taking a look. It works with both Cargo.toml and .cargo/config.toml

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

No branches or pull requests

5 participants