-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Local Git dependency using relative file path #6859
Comments
To anyone trying to do this, as a workaround, you could checkout the right version of the dependency as a Git sub-module at the chosen path, then use a relative path in the Cargo config. |
This solution doesn't work when you use workspaces and the submodule in question is also a workspace, though. |
While submodules work, they have one big disadvantage: if a crate What should relative git URLs be relative to? I see two obvious candidates:
(2) is how relative URLs in
Support for relative URLs in Is this a good idea? Are PRs sought for this feature? |
After a quick reading of the source code, I find the following barriers to implementation:
Projects which use this feature would no longer build when exported from git (i.e., via In addition, the TOML requires that the git repository address be a URL. This means that the address will require an URL scheme : There are probably other issues here, but these are the ones I could find. |
Alternatively, maybe trying to re-invent git submodules in cargo is fighting too much inertia. Cargo really wants crates to be identified by URL. Rather than trying to infer a base URL from the environment, we could create an URL scheme for explicit indirection. We could allow the user to create repository groups within [repogroups]
awesome = "ssh://[email protected]/git" and use like this within [dependencies]
baz = { git = "repogroup://awesome/project/baz.git" } which would expand to " I see this functionality as a lightweight alternative to custom registries. One can use this to make repository trees that can be relocated anywhere, and the "anywhere" is left to the discretion of the developer. @fluffysquirrels: Any opinions? |
@cbs228 What do you mean by this? |
@jplatte For unpublished crates, like git dependencies, Cargo strongly couples the notion of identity with URL. To identify a crate—that is, its name and version—it is also necessary to specify where absolutely the crate can be obtained. URLs must be absolute, and everyone must be able to retrieve the same URL. This starts to become a problem when you have forks and/or mirrors. It is difficult to The obvious workarounds are Git submodules and/or subtrees. There is also a way to use Git itself to replace URLs, which I described here. I am looking to improve the user experience for no-shared-infrastructure distributed development. What's the best way to have an ecosystem of crates without a package server like crates.io? I'm not sure there's a good answer for this yet, but if there is one, I'd appreciate some enlightenment. |
Nice to have! |
Absolutely necessary. |
Also, what @cbs228 seems to be discussing seems a lot more complicated the basic version of this feature needs to be. In general, anywhere a git repo can be used, it should be possible to use a local file. |
Not caught up on all of this yet but SCP-like URLs were supported for git submodules in #12359. |
It would be nice to have this. With this I would have been able to easily use an old version from an internal crate.
|
@ghost proposed in issue #2252 :
The text was updated successfully, but these errors were encountered: