Rust's package management is actually a downside to my adoption. I have a lot of C++, a home-grown package manager, and a large cmake based build system. Rust wants to replace all this, but that means shelling out to Rust's build system, which is a bit of a messy situation and means I need to learn a new build system with the language. (not hard, but another thing to learn). Our home grown package manager means we have our own local copy of everything - I have a hard requriement to be able to rebuild software for the next 15 years (there is a closet someplace with a windows XP service pack 1 PC so we can build some old software - God only knows if it will boot anymore). In the embedded space we need to support our old code for years, and you can't always upgrade to the latest.
"cargo vendor" enables you to embed your entire dependency tree into your repo instantly, and compilation will work from that. Over half of your comment seems to have been predicated on the assumption that this either wasn't possible or wasn't easy... so I think your perceptions of Rust's package management system are more of an impediment to you than the actual package management system.
While I will admit ignorance about the details of Rust, what you described doesn't solve my problem. We do not believe in mono-repo here, and have broken our system down into lots of small repos with custom tools to manage that. Checking in a copy of the dependency tree into each repo is not the right answer. I'm sure I can make this all work, but everything I've heard about Cargo is it will fight the way we have setup our system. We are not changing, while there are things I'd do different (use Conan - but that didn't exist until just after we rolled our system out, and is just enough different that it will be hard to switch), the system works for our needs.
Cargo will allow you to solve this problem half a dozen ways. I’m certain at least one of those ways would fit the patterns you’re describing.
But you keep coming back to this idea of how Rust has to fit your workflow perfectly and you’re unwilling to make any changes to have things work better with Rust...
If you’re unwilling to change anything at all, then it’s laughable to imply that you would use an entirely different programming language for anything, even if it fits your workflow exactly.
So, I just don’t see the purpose of this discussion. You’re basically saying that you’re not going to use Rust, no matter what Rust does or does not do. That’s neat?
It sounds like you're implying git submodules are actually a good thing... I think you're the first person who has implied such a thing to me before. Everyone I actually know agrees that submodules are basically never the right solution or a pleasant solution.
But, to your question, no. Where would the submodules even point? The dependency source code artifacts are stored "immutably" (except for takedown notices or extreme abuse cases) on https://crates.io. They aren't git repos, and there's nowhere for git to point.
Yeah: using submodules makes maintaining vendor patches (which, FWIW, I pretty much don't do and will move mountains to avoid... but like, I totally appreciate why people do them) really natural and easy. Like, you don't just want a copy of the code: you want to be able to participate in the development of the upstream code with the same level of tooling that they have, and submodules does that.
The approach here would be to declare the dependency on the git repo directly. Vendoring is still going to copy the stuff you're building into your project, but you'd keep those patches in the repository of the dependency, not on your vendored copy.
The key thing here is being able to do it through multiple levels of dependency, for which I see someone else provided me an answer that is actionable! \o/
People definitely have strong opinions on submodules, but it is nowhere near so one-sides: a ton of people hate them, and a ton of people swear by them. FWIW, all of the Rust libraries I use are available as git repositories. With many other package managers, I can tell them "don't use the upstream copy from the package repo: use the copy I have in this folder" in a trivial manner. I thereby don't really want "automation" around either downloading the code for me to mirror or for the submodules I want: I want to set it up and then configure it so it is all "honored"... and I could totally see the feature you talking about somehow only working one way (with automatic copies) instead of being flexible.
Yes, it can pick dependencies from checked out submodules, or git URLs directly. It has ways to patch individual dependencies anywhere in the dependency tree, and multiple ways to mirror or replace the whole crates.io index. It's pretty flexible in this regard.
I’m not here to argue one way or another on dependency vendoring. The person I replied to was making an inordinately big deal about how they keep code around forever and it compiles decades later, as if Rust dependencies were some ephemeral thing that would break your code by next Monday!
If they want to reproduce their workflow using Rust, cargo allows vendoring and many other solutions.
