rust and cargo are both such a nightmare to use, I really hope the RIIR meme dies out soon... I actually like that I can compile code without an internet connection.
rust and cargo are both such a nightmare to use, I really hope the RIIR meme dies out soon... I actually like that I can compile code without an internet connection.
My issues with cargo, are less about the tool in isolation, but more how it's used. IMO Dependencies should be avoided by default, cargo encourages bad habits. If cargo as a tool behaved more like pip, where you'd call `cargo install dependency` and then completely unconnected `rustc build`. I'd have no issues with cargo. (Also note, pip has many more problems than cargo, but at least you don't use your package manager to run your python code)
It's possible I've still jaded because the first time I had to actually use cargo, it was setting it up for my team to work on it, and have it function, from within an air gapped network... never again!
This has the problem that your deps can get out of sync with your lockfile... which is why most/all the newer python package managers have a run command that works more like cargo e.g. https://python-poetry.org/docs/basic-usage/#using-poetry-run
If you tried it a while ago things likely improved since then. `cargo fetch` and `cargo vendor` are both single-command solutions for airgapped networks.
Cargo does have an `offline` mode for `cargo build` which won't hit the network, and you can vendor dependencies. You can also invoke `rustc` directly outside of Cargo. In general though I think the Cargo team is optimizing usability for the 90%ile who can and do use the internet while developing (which is also unavoidable with other language ecosystems). But getting stuck if you're in that 10% is always hard.
That's what unsafe is for. From the rust book:
"Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.” Be warned, however, that you use unsafe Rust at your own risk: if you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing."
If you find it aggravating to use, then it’s not likely this will make you happy but just in case it helps, you can just bake it into your image and be completely airgapped and the only real factor is storage because the actual functionality is easy.
local du -h -d 1 .
214G ./crates
33G ./dist
830M ./rustup
2.7G ./crates.io-index
250G
I'm fairly indiscriminate with my setup. I just used defaults everywhere.I don't want to assume too much about your specific use case, but in a lot of situations that people describe this way, the truth is that the code would've been correct if it was C but -- because it violates the no-mutable-aliasing rule -- it's genuinely broken under the Rust memory model and will trigger UB if you use unsafe code to work around the compiler errors. https://youtu.be/DG-VLezRkYQ
You can use the 'cargo vendor' command to download all of a project's dependencies and then transfer them to an air-gapped environment.
https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
This allows for the project's dependencies to be checked before they are introduced in the air-gapped environment and also placed in version control for a full snapshot of the project.
At $WORK we have been using Rust this way for a few years now and it has been great. Cargo is much easier to use than cmake, make, and other custom build scripts we were using before. After a few trials, we have been migrating projects from C/C++ to Rust and management has been impressed with the results. The code is equally fast, errors are down, and our velocity is improving since we find and correct more problems earlier in our processes.