3 ms·
> is there a sustainable way of working/developing with Rust while completely offline? Yes. Once you have downloaded your dependencies the first time while onl
by codetrotter 7y ago
> is there a sustainable way of working/developing with Rust while completely offline?
Yes. Once you have downloaded your dependencies the first time while online you are able to work with them completely offline.
> read documentation
Rust docs:
rustup downloads docs for Rust itself alongside the toolchain when you download it.
`rustup doc --book` will open the locally downloaded copy of the book The Rust Programming Language in your browser.
`rustup doc` will open the locally downloaded copy of the overview of Rust Documentation in your browser. The locally downloaded docs include things like the docs for the Rust Standard Library.
Project and dependencies docs:
`cargo doc --open' will build the docs for your project and for your dependencies as offline HTML files and open the locally build docs in your web browser for you.
Subsequently running the same command while offline will open the already built docs in your web browser again.
You will find the built docs under target/doc/ in your project. This includes the docs for your dependencies and their dependencies and so on.
And even if you delete the built docs, for example by running `cargo clean', cargo can rebuild the docs offline because it has cached the source code of your dependencies and their dependencies and so on.
> manually import libraries (downloaded manually, no dependency hell)
Rather than attempt to do it manually I would advice that you run `cargo build' once while online, so that your dependencies are fetched and made available offline. Attempting to do it completely manually has no benefit that I can see and would only serve to waste time and probably introduce problems that would not happen if you leave it to cargo to fetch it all for you.
And you can write crates of your own locally, never publish them online and import them by relative local path.
- jakobdabo 7y agoThank your for the detailed answer. > Attempting to do it completely manually has no benefit that I can see Package managers and build tools can do basically whatever they want - run commands, execute binaries, download data, upload data, send telemetry - whatever any one of the package maintainers wants. I prefer to develop in an offline VM. When a new library is required I just download it using the host machine, copy into VM and use it there. It's easy with make/cMake.
- gfs 7y agoI totally understand your desire to develop things in a sandboxed environment but the source code for Rust/Cargo/Etc. is all available under their organization at GitHub. [0] It would be easy to audit and raise issues if you have any concerns. [0]: https://github.com/rust-lang https://github.com/rust-lang
- wbond 7y agoAuditing rust and cargo sounds like easily 1000x more work than copying some source files.
- woah 7y agoWhy is it more important to audit cargo than it is to audit your dependencies?
- wbond 7y agoI have zero interest in auditing cargo.
- burntsushi 7y agoReally? How did you get the source code for those dependencies in the first place? Whatever you used likely has just as much power as Cargo does. (And is perhaps similarly hard to audit.)
- wbond 7y agoA well-tested, regularly audited web browser that is subjected to hacking competitions with monetarily significant rewards. However, at this point I think we are WAY off the original topic. :-)
- burntsushi 7y agoIt's not really off topic because you're hiding a super niche use case behind misleading language. e.g., You present two choices: "audit Cargo" or "copy some source files." But those aren't actually the two choices in practice, because in order to copy the source files, you actually need to obtain them first. And in order to obtain them, you very likely need to use some software to do it. And the most common pieces of software you might use to obtain said files are likely just as hard (or harder) to audit than Cargo is. So upon further clarification, it's much clearer what your position is: "auditing Cargo myself is much harder than trusting the security of some other piece of software that has been---and continues to be---subjected to rigorous auditing by either teams of people I trust or by systematic processes that I trust." But of course, this doesn't sound nearly as nice as, "why would I audit Cargo instead of just copying some source files." Hence, it's misleading. Once you expose your actual stance, IMO, it's pretty easy to say: "oh okay, you are in a particularly interesting niche which, while may be important, is likely not possible to serve right now. So you'll have to continue avoiding Cargo or otherwise wait until it has met your arbitrary requirements for auditing." But it should be supremely clear that the vast majority of people are not in your position. (And I suppose that would be your cue for some snarky response about how this reflects poorly on the state of software engineering.)