@ratmice: Are you trying to use a local registry as an alternative to [patch] with a path or git repository? I've not tried it, but that sounds like it could be a lot of work.
If we had some form of .cargo/config "source replacement" for git repositories, it would be less necessary to switch between path and git patches. You could define the git URL via your own personal environment. It would still be necessary to use [patch] to switch to an unpublished version, but then you could staple it to a particular branch and just use that.
The existing source replacement feature in .cargo/config can only replace the crate index in its entirety, which is not what we want.
@cbs228 yes, a local registry as an alternative to [patch] basically.
But populating the local registry from git repositories, by having a mechanism to:
enumerate versions from some working dir.
a map from version to sha1.
ensuring bit for bit reproducible source release process.
So In essence my "local registry" is populated by seaching some root for ./*/Cargo.toml, going through the above 3 steps, and populating the registry contents from the repository contents.
Anyhow, i'm mostly just spit-balling because this mechanism has a very low bar from taking an arbitrary crate, and using it in a distributed fashion without really modifying it's [dependencies] section. The changes required are to making the above 3 steps feasible to do and check.
@ratmice, yes, it certainly sounds like the registry changes are a separate feature. Would easier local replacement of git sources help you at all?
It looks like PR 7199 is relevant. It discusses the possibility of adding [patch] support to the Cargo configuration files, as @CAD97 suggested. The use of paths = […] was recommended as a potential alternative, but this does not work for unpublished crates.
It would definitely be an improvement, in that I could just have a few config.local_fs config.local_git and swap .cargo/config via symlink as needed absent any kind of option to specify .cargo/config.
I don't really work with unpublished crates enough (except in the initial stages of creation), for that limitation to be a real nuisance.
@ratmice, some additional research indicates that there is a source replacement mechanism for git repositories. It was introduced in #3992, which was added to support vendoring dependencies from git repositories. The output from cargo vendor looks something like this:
.cargo/config
[source."ssh://git@somewhere/foo.git"]
# the source you are replacing
git = "ssh://git@somewhere/foo.git"
branch = "master"
replace-with = "vendored-sources"
[source.vendored-sources]
# the source you are replacing it with
directory = "vendor"
One can use this to replace git sources with an online registry, a cargo-local-registry, or a directory-as-registry. This mechanism does not touch the dependency graph. It merely provides an alternative method to obtain the dependency's sources. I believe that an existing Cargo.lock file is also required.
This does not help me at all. I want to replace several git repos with local mirrors, without touching the dependency graph or the crates sources themselves. It does not appear that one can use this to replace one git repository with another. The requirement for a pre-existing Cargo.lock file is also a non-starter for me.
Most of the problems I put forward in this thread can be solved by git itself.
In this thread, I proposed changes to the way that cargo downloads crates from git [dependencies]. Git-hosted crates are identified in the dependency graph by—among other things—their repository URL and a commit hash. I wanted to de-couple the identifying URL from where the crate is actually downloaded. This "redirection" allows the use of local git mirrors instead of networked repositories.
As far as cargo is concerned, the crate's URL remains sftp://git@my-server/whatever.git. Git replaces the URL internally during fetch operations, using prefix matching. Cargo remains unaware of this substitution, and it will continue to refer to the crate in Cargo.lock by its original URL. For further reading, see git-config and search for "insteadOf."
Given this, changes to cargo are likely not required in order to support my use-case. I hope this helps anyone using similar workflows.