I am using a mirror of crates.io on my local network. It is updated manually by ticket with long delays, so I am trying to find a solution that doesn't require an update. I have a project that requires the dlmalloc crate. My mirror has dlmalloc up to version 0.2.9. My project fails to build because it is looking for, and failing to find, version 0.2.10. I have looked exhaustively through every Cargo.toml in the project, and everywhere dlmalloc is needed, if it doesn't have a version number, I manually specify 0.2.9 in it. Furthermore, I haven't found any Cargo.tomls that specify needing version 0.2.10.
To my mind it should not be looking for 0.2.10 at all, but despite these steps, when I run cargo build, I still get the error that it fails to find dlmalloc version 0.2.10. So I think my main question is, why is it still looking for version 0.2.10, when it explicitly shouldn't be?
I have a separate problem when trying to run a MWE to solve this, which may be helpful. I created a test_project, left it completely empty, and added one common dependency (rand 0.8), and as a diagnostic, ran cargo tree -i test_project. The output is just "test_project v0.1.0 (/path/to/test_project)" I don't know what to expect from cargo tree, but I was under the impression it should show the rand dependency in the tree somewhere. I cannot run cargo tree on the main project, as it does not build.
do you mirror only the crates (using the source.crates-io.replace-with cargo configuration), or do you also mirror the index of crates.io (e.g. using something like cargo local-registry and set the registry.default configuration)?
did you check the lock file? 0.2.10 is semver compatible with 0.2.9, so if the manifest specifies 0.2.9, cargo can resolve to 0.2.10, either according to the lock file, or by inquiring the index when there's no lock file.
the -i option outputs the inversed edges of the dependency graph, or in other words, it prints the dependants (as opposed to dependencies) of a given package. in this example, you should specify rand, not test_project:
I think I mirror both crates and index, but it's slightly different. My config has 3 lines:
[source.mirror-name] registry = "http://mirror-name/git/crates.io-index"
[source.mirror-name-sparse] registry = "http://mirror-name/index/"
[source.crates-io] replace-with = "mirror-name"
When troubleshooting, I've been routinely deleting all the lock files, as that's solved similar problems in the past. However, I haven't been inspecting their contents, Are you suggesting 0.2.10 may be popping up in there somehow? Also, 0.2.6 or 0.2.7 should work as well, as those are the only versions specified in the project, when a version is specified at all. Could replacing all the instances of 0.2.9 with 0.2.6 solve this problem?
Thanks for explaining the usage of tree! That makes sense and explains the results. cargo tree -i rand behaves correctly as you suggest.
When I run cargo tree in the main project without the -i option, I get a large tree, which has only one mention of dlmalloc, and it's v0.2.9.
if you deleted the lock file, cargo build will generate a new lock file using the newest version found in the registry index that is semver compatible.
so based on your description, I think your local registry have updated the index to include 0.2.10, but the crates source is not updated yet.
in this case, specifying 0.2.6 or 0.2.7 should all be resolved to 0.2.10, since that's the newest version of 0.2.x in the index.
if the registry cannot be updated in time, you can edit your manifest to change the version requirement for the crate using comparison operator to restrict to the available versions instead, for example:
[dependencies]
# `=` will only match the EXACT version (major.minor.patch)
dlmalloc = "=0.2.7"
# alternatively, you can use `<=`
dlmmaloc = "<= 0.2.9"
if that's the case, it might be a cargo bug. the cargo tree command should print the resolved dependency graph, not the specified versions. so if it prints 0.2.9, it should use 0.2.9 when building, not 0.2.10.
but you say it's a giant tree, can you double check just with cargo tree -i dlmalloc?
btw, I noticed you have a separate sparse index mirror-name-sparse, but the url didn't specify sparse+http://...., also you replaced crates-io with the git index instead of the sparse index. did you try to switch to the sparse index instead? maybe the registry administrator updated the git index separately from the crate sources and sparse index?