Crates downloaded from crates.io can just be put into the vendored-sources directory.
However a referenced git repository might contain multiple crates in a so-called "workspace".
If we put such a workspace into the vendor folder, cargo fails with
found a virtual manifest at [...]Cargo.toml instead of a package manifest
This solution uses a separate folder for sources downloaded from git repositories and checks them for workspaces.
If they are "regular", i.e. don't have a workspace, they are put to the vendored sources from crates.io.
Otherwise they are left in the git-vendor directory.
Additionally refine the config.toml entry for sources vendored from git. This allows to override a specific git URL and revision with the path to the extracted repository.
Otherwise we would need entries for each crate in workspaces but then cargo tries to verify the revision and fails with
Micket
commented
1 week ago
Crates downloaded from crates.io can just be put into the vendored-sources directory. However a referenced git repository might contain multiple crates in a so-called "workspace". If we put such a workspace into the vendor folder, cargo fails with
This solution uses a separate folder for sources downloaded from git repositories and checks them for workspaces. If they are "regular", i.e. don't have a workspace, they are put to the vendored sources from crates.io. Otherwise they are left in the git-vendor directory.
Additionally refine the config.toml entry for sources vendored from git. This allows to override a specific git URL and revision with the path to the extracted repository. Otherwise we would need entries for each crate in workspaces but then cargo tries to verify the revision and fails with
I also have a Stack Overflow question on that in case there is a better solution: https://stackoverflow.com/questions/79065892/how-to-patch-a-cargo-git-dependency-that-contains-a-workspace