I already locally have all the crates I need for the application I'm attempting to build on my computer, as I have built this application years ago when specific crates were not deprecated and would like to set this up to build this application when no internet access is available with all crates local with the code.
$ cargo vendor
Updating crates.io index
error: failed to sync
Caused by:
failed to load pkg lockfile
Caused by:
failed to select a version for the requirement `aes = "^0.2"`
candidate versions found which didn't match: 0.8.2, 0.8.1, 0.8.0, ...
location searched: crates.io index
Next I went to crates.io and have found that the aes 0.2.x package has been deprecated. There are numerous crates, so is there a way I can manually copy those crates, including this aes-0.2.0 crate, from my ~/.cargo directory to the application's code within the vendor folder? I see something similar in the cargo vendor example for the smallvec crate where the code is able to be run with cargo build --offline and it will always use smallvec crate version 1.6.1 but unfortunately that example is using a version of a crate which has not been deprecated, so a cargo vendor would work perfectly fine. This example also is using only one crate, so does anyone have any example code which cargo vendor with many crates?
I'm not sure where to go here but I have all the crates locally in my ~/.cargo directory and need to get them to integrate with this application's code so that users can cargo build --offline successfully. Thank you for any help you can give.
Also as an aside, I was not able to find the aes crate in the crates.io-index here, so thought that was strange.
The simplest way to do this (aside from modifying the code to use a newer version) is probably to patch in the yanked versions of the offending crates from their originating Git repos, and repeat with their dependencies until cargo vendor stops complaining. In this case, I had to add 5 old versions of crates:
Thank you for the response @LegionMammal978 and the great information you supplied. I should have stated before that I don't know how to write rust code but that I do have some basic understanding of rust & cargo as I did read the beginning of the rust book but did not have the time to read most of it thru it to the end.
One or two years ago, I began with a rust application that compiled fine. The code never changed and the build always worked until recently due to some crate deprecation. I would agree that modifying the code to use a newer version would be the best option, but I don't know rust so that's not an option for me at this time. I find great ethusiasm in saying that by using the information you provided that this application once again compiles!
The strangeness that I don't understand here is that I'm not able to run cargo build --release --offline without first running cargo vendor. Then a sequential git diff shows no differences to commit to the repo to make it reproducibly build completely offline. I've followed the same process above & it worked successfully on Ubuntu 20.04 and Arch Linux with rustc 1.65.0. Do you or any other rustaceans have any ideas on how to truly build this application completely offline?
Well, you have to get the dependencies onto your system somehow. First, unless you already have a Cargo.lock file that pins the dependency versions, you have to add that [patch.crates-io] section to Cargo.toml to get the old versions of yanked crates directly from their Git repos. Then, you have two options.
The first option is to run cargo fetch. This downloads all of the dependencies and places them in Cargo's global registry. Then, you can run cargo build --offline whenever you want. However, it will not work if you move the repo to another machine without Internet access.
The second option is to run cargo vendor. This downloads all of the dependencies to Cargo's registry, copies them into the vendor directory, and outputs instructions for how to modify your .cargo/config.toml so that Cargo looks for them in the vendor directory. Then, it will always work, even if you move the repo to another machine. (As an aside, after you run cargo vendor and follow its instructions, you are free to remove the [patch.crates-io] section in Cargo.toml and the [source."https://github.com/..."] sections in .cargo/config.toml. Then, Cargo will look in what it thinks is crates.io for the old versions, which is actually just the vendor directory.)
In the future, if you have an application, it's often helpful to save the Cargo.lock file alongside the Cargo.toml file. Cargo.lock is automatically generated by cargo update, as well as most other Cargo commands. If your project has a Cargo.lock file, then Cargo will always be able to pull old crate versions from crates.io, even if they have since been yanked.
Finally, most crate authors don't follow the practice of yanking their old crate versions as a form of deprecation, unless there's some crippling security issue. So this problem isn't very common for most applications (though it's very annoying when it does occur). To me, the odd part here is why the publisher of aes decided in 2021 to yank its old versions: they did not cite any security concerns on their GitHub repo, nor on any other documentation. Yanking crates without justification is considered rude by some, since it can lead to these issues with building old applications.