@djc, the specific things I am interested in doing include:
-
"Publish" to git repositories instead of to a registry. This is already well-supported in Cargo. I am not interested in setting up a registry.
-
Take my repositories "on the road," by mirroring them, so that I can use them in the field without needing a network connection back to my server. I want to be able to do full development work on any or all of my crates; not just a top-level crate. I'd like this to be as painless as possible: ideally, I could mass-correct all my git
[dependencies]by changing one line in a config file under~/.cargoor the like. This also needs to work across URL schemes: my main git server usesssh://, but when I am on the road I might want to usefile://.
When is say "distributed workflows," I mostly mean that I want to take advantage of the fact that git is decentralized and is easily mirrored and forked in multiple places.
@kornel, at present I use git submodules with [path] dependencies. Submodules can have relative URLs, and the URL is interpreted relative to that of the remote tracking branch. To change locations, all I need to do is change where my origin in the top-level project points. This solution is acceptable for projects with simple, one-level dependency graphs. The minute you add more than one level of dependency, things get ugly very quickly. One winds up redoing a lot of the packaging work done by the lower-level projects.
The solution proposed by @CAD97 is certainly an alternative. In this case, however, I have to [patch] whatever I want to build. This requires introducing more commits whose sole purpose is to change URLs. I would rather avoid doing this, as it adds to clutter, merge conflicts, and said commits will definitely break things for others if accidentally merged. I would much rather be able to redirect en masse without needing to touch my VCS.