# What is the current best practice to fix a broken package install?

**URL:** <https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320>\
**Category:** General Usage\
**Tags:** package, installation\
**Created:** [September 9, 2026, 11:56pm UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320 "2026-09-09T23:56:03Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 9, 2026, 11:56pm UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320/1 "2026-09-09T23:56:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 10, 2026, 5:53am UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320/2 "2026-09-10T05:53:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 10, 2026, 6:14am UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320/3 "2026-09-10T06:14:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 10, 2026, 6:57am UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320/4 "2026-09-10T06:57:15Z")

</div>

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](https://github.com/JuliaLang/Pkg.jl/blob/49373a075dd4be9adc4efe7c9b134e518aa7ddc2/src/Operations.jl#L1229-L1294)

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 10, 2026, 7:14am UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320/5 "2026-09-10T07:14:59Z")

</div>

(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.)

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 10, 2026, 8:47pm UTC](https://discourse.julialang.org/t/what-is-the-current-best-practice-to-fix-a-broken-package-install/139320/6 "2026-09-10T20:47:38Z")

</div>

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:

- [advice for recovering from corrupted depot in the manual · Issue #1683 · JuliaLang/Pkg.jl](https://github.com/JuliaLang/Pkg.jl/issues/1683)
- [KristofferC/PkgFsck.jl · GitHub](https://github.com/KristofferC/PkgFsck.jl)