As someone using spinning rust, having a background process hammering the disk is absolutely visible to the user. I’d be angry at an installer doing that in the background where I can’t stop it, without any indication as to how long it’ll be before I can use the disk again.
Too me 3-4 minutes is bad, but not a unbearable amount of time. To feel reassured, a progress indicator would be enough.
But with Trend Micro Office Scan, you really wonder if rustup is not hanging : it may take hours to install the docs.
Unsure how that would affect the experience, but Windows does famously have their CHM format, which is essentially (I think) a zip of many HTML files, that are directly viewable natively without extracting. Could this be used?
Which (AFAIK) is deprecated, and doesn’t support Unicode. Also, the HTML Help viewer itself is pretty janky, what with it effectively being an embedded IE with a table of contents (good), and no tabs (very bad).
Of the docs, core has 10 123 files and std 2722. Removing all the files with little content in them is one workaround. Adding them together into a larger file is another. A script could do so, perhaps.
Windows Search file indexer is part of the problem.
Creating a PDF from the web pages could be possible: https://helpx.adobe.com/acrobat/using/converting-web-pages-pdf.html
I created an issue to consider creating a progress bar for
rustup component installs. While this in no way solves the problem, I think it is at least a step forward and (if not too difficult to implement) is universally helpful.
There are a lot of extra files that redirect, like
from_mut.v.html is a redirect to
fn.from_mut.html and so on for every function and type, at least. Is there a plan to move away from these? It would be good to find some point where they can be removed or replaced with some built in rustdoc smarts.
The docs directory can take up a lot of space too. If NTFS compression was enabled, it would take up a lot less space and less blocks would have to be actually written to disk, ultimately saving time.
I’m lately mostly using devdocs.io which just runs in the browser and allows precaching docs for various languages and libs (including Rust ones) for offline use by storing them in the IndexedDB. Could regular Rust docs switch to the same approach? Then we wouldn’t even need an installation step nor a problematic number of files. All that user would have to do is open https://doc.rust-lang.org/ to have docs cache updated to the latest one.
That looks like an almost-good approach. It looks like devdocs is missing some of the docs though. Also, the caching is not 100% reliable it seems. this could be fixed, perhaps. It’s similar to the http server approach in some ways.
My initial thought was that’s it’s super tricky to make rustup “install” the offline docs in the browser and ensure they stay long enough… but that’s actually not necessary. We can assume Rust users will open the docs page anyway, and they’ll probably use it often enough to keep it cached.
So I like that. It entirely shifts the problem from “docs are slow to install” to “docs don’t even need an install”.
The whole point of installing docs locally is to… install them locally. For when you don’t have a network connection, or for computers that don’t/aren’t allowed to have unfettered internet access.
Relying on an unaffiliated, third-party web service that only serves the current stable docs (which might or might not be what you’re using), in an unfamiliar structure, and which has an apparently unreliable caching system would seem to defeat the purpose.
I’m not talking about the devdocs service, but about making the official docs.rlo work offline. This can be achieved by adding an offline-caching service worker to the official docs page.
To me that’s even better than having docs installed offline, because the offline docs are a separate thing, opened with another command. So this:
- Try docs.rlo
- Oops, I’m offline
can be simplified to:
- Try docs.rlo. Keeps working offline
rustdoc doc can be changed to open docs.rlo URL)
That’s far beside the point. The problem I am seeing is: at the end of the updating done by Rustup it hangs. The CPU and disk usages are both zero. I don’t know what’s happening but it’s not copying files, nor scanning them. And I’ve kept the shell open for hours with no changes. I have reported this here:
And I am thinking about reopening that issue.
Interesting, that hasn’t been my experience with the problem (for me there is clear CPU and disk activity during
rust-docs install, it just takes a super long time). I agree a progress bar would probably not be helpful in that situation.
I added this data point to the current open issue so that it’s not lost.
You appear to have ignored my first paragraph:
For when you don’t have a network connection, or for computers that don’t/aren’t allowed to have unfettered internet access.
(Even that’s ignoring that I’ve never seen a “works offline” website that actually reliably worked offline, but I’ve been avoiding that because it’s not as strong a point.)
Also, you’re projecting your own behaviour to invalidate others’ arguments. Here’s how I use docs:
- Type “rustdoc blah” into address bar, which opens the local docs and searches for “blah”.
Adding caching to the docs website is an entirely reasonable thing to do. It also in no way addresses the need for local docs, nor does it address them being slow to install on Windows.
Let me put it like this: people are complaining that the city has an issue with the main highway being highly congested as people try to drive to work. There are suggestions of enforced car pooling, adding more public transport, adding more roads…
You’re suggesting outsourcing all jobs in the city to China. Yes, that would solve the congestion problem, but conveniently ignores why people want jobs in the first place.
Such files shouldn’t be generated anymore. Could you open an issue about it please?