What happens if ``Pkg.add`` and ``Pkg.update`` fail or get interrupted?

Will the failure or interruption of Pkg.add and Pkg.update cause any problems to the Julia packages I already have installed?

I had Gurobi.jl in my Julia 1.4.2 and I was trying to update it to the most recent version by doing Pkg.add("Gurobi"). But it failed due to **ERROR:** Unsatisfiable requirements detected for package ...

I then tried Pkg.update("Gurobi"), which did not finish after a long time. So I did control+c to stop it and got **ERROR:** InterruptException:.

I finally decided to first stay with the old version I already have and do not do the update.

Now at this point, have the failure and interrupt of Pkg.add and Pkg.update caused any problems to the current Gurobi.jl and other packages I already have installed before?

Some of my codes which worked before still seem to work now, so I assume there is no change, but I just want to make sure is there anything I have to fix?

Thanks.

1 Like

no (unless your registry of something gets corrupted, but usually it has nothing to do with failure due to unsatisfiability or you Ctrl-C ed it)

1 Like

Thanks! How about other operations such as Pkg.build?

Can I always safely control+c these operations without affecting other things?

If something is canceled, it will just continue/start over the next time.

Your phone wouldn’t brick just because you canceled an app installation would it?

1 Like

I’ve found ctrl-c during git operations can lead to registry corruption: `ctrl-c` during registry updates leads to corruption · Issue #2584 · JuliaLang/Pkg.jl · GitHub. It is very easy to fix if you know what is happening and what to do: just ] registry rm General followed by ] registry add General. These commands won’t affect installed packages; they just remove and reinstall the registry itself.

The automatic precompilation introduced in v1.6 on the other hand is documented as safe to interrupt.

For Pkg.build, that is running whatever code the package author wrote for their build step, so it depends on that code and if they wrote it in a way that is safe to interrupt.

2 Likes

Thanks for sharing! May I ask how you were able to find out there was corruption? Was it because your code was not running? Are there ways to find out corruption whose occurrence is silent and does not raise an error?

The way I found out is on trying to install a package I’d get error messages like

Unsatisfiable requirements detected for package […].
… […] has no known versions!*

when I know that the package definitely does have versions in the registry. I don’t know how to detect silent corruption but reinstalling the registry would still fix it. I guess you could clone the registry yourself and diff against the one you have on disk to see if there’s any differences.