Haven’t run into this personally yet, but it’s been on my mind. Say Package@v1.2.3 is not working properly in a given environment, but I do not know why and want to reinstall it and its dependencies in case a file got corrupted. I can rm it from the environment, but that doesn’t touch the central installation. update installs another version without touching the broken one that might remain in other environments. If all the active environments happen to not have that package version, I could gc it, but that might not touch an unknown broken dependency, and I really prefer not to tweak every environment just to reinstall then re-add it. I could manually delete files from the .julia folder, but I don’t know how to identify the broken files to save work or the possible dependencies to be safe, and nuking the entire folder or subfolders is overkill that is only tolerable for first-time users. I’m hoping I just missed something obvious or that someone else figured out something.
To begin with, if you have problems with files getting corrupted, it would seem wise to replace your storage hardware and start over with a fresh install.
If you just want to rule out that there’s something wrong with your existing installation, pointing JULIA_DEPOT_PATH to an empty directory and instantiating your environment should take you a long way. Then you can run your tests and see if the problem persists, or compare the contents of your temporary depot to corresponding entries in your .julia directory.
The temporary depot change is clever.
Is bad storage the only practical cause of broken installs though? Internet or power issues mid-download seem plausible too.
Packages are unpacked in a temporary location and moved into the final destination after integrity checking [1]. I can’t tell whether there is any scenario where a power failure leads to a corrupt result but internet issues definitely shouldn’t.
[1] Pkg.jl/src/Operations.jl at 49373a075dd4be9adc4efe7c9b134e518aa7ddc2 · JuliaLang/Pkg.jl · GitHub
(For many packages you can do the same integrity checking at any later time, but it may fail if the package has a build step, or unwisely mutates its contents rather than using the Preferences or Scratch stdlibs.)
I suppose a power issue can interfere in the move? In any case, that helps explain why I haven’t personally ran into it. The exact reason why it’s been on my mind is that last week, someone trying Julia for the first time ran into a problem with precompiling an undisclosed version of Pluto that could be redone after nuking the .julia folder and reinstalling Julia. The cause isn’t really important there, I just couldn’t think of a less drastic measure to reinstall one problematic package and its dependencies in one environment. Related, though I’m not convinced that testing for corruption instead of a direct reinstall is worth the false negatives: