Fix install_version skipping download when files are missing from disk

[KristofferC]

This felt annoying:

❯ juliaup rm 1.12.6      
    Deleting symlink julia-1.12.6.
      Tidyup No unused Julia installations to clean up.
      Remove Julia channel '1.12.6' successfully removed.

❯ juliaup add 1.12.6
    Checking for new Julia versions
         Add Installed Julia channel '1.12.6'

❯ julia +1.12.6                         
Error: The Julia launcher failed to determine the command for the `1.12.6` channel.

Caused by:
    0: Failed to normalize path for Julia binary, starting from `/Users/kc/.julia/juliaup/juliaup.json`.
    1: No such file or directory (os error 2)

I think add should check that the folder exist and otherwise redownload. That is what this PR does.

[davidanthoff]

Hm, what is going on there? Do you still have a different channel that keeps that version around? In general, when you remove a channel and it reports that nothing needs to be tidied up, that should (I think) mean that the version that this channel pointed to is still pointed to by some other channel and doesn't need to be removed. And then when the add happens it should just need to add the channel to the config file, but the version should already be there.

So I don't really understand how this error can occur in the first place?

[davidanthoff]

Oh, wait, is this also a situation where you deleted files manually from disc?

I think maybe generally when we detect a situation where the config file and the situation on disc is out of sync we should throw an error that states something like "Your Juliaup configuration is corrupted, please run juliaup fixconfiguration or something like that, and then have a new command that does something meaningful to fix the situation. I think that is more realistic than trying to handle corrupted configuration situations in every single command in some robust way.

[KristofferC]

If I do pkg add and a package in your environment is not downloaded it doesn't crash and tell you to fix things. It just handles it. The failure mode for this specific case is worth handling gracefully in my opinion.

[davidanthoff]

There is a design philosophy difference between Pkg.jl and Juliaup: Juliaup tracks everything that is installed in the config file, and assumes that the config file and the state of downloads is consistent. If that invariant doesn't hold, a lot of things won't work properly. Pkg.jl doesn't have that concept of a global configuration file that tracks which packages are installed, so (AFAIK) it doesn't have this consistency problem.

I'm just saying, once the config file and the file system state inside the juliaup folder are out of sync, things will go haywire left and right, not just in the scenarios that are fixed by this PR here. So one approach could be to then try to handle data corruption individually in each of these cases. I think that just adds too much complexity to a scenario that at the end of the day is a corner case that only occurs if a user started to manually manipulate files that they should not have manipulated in the first place. I think in such cases it is fair to just offer a kind of "cleanup" command and alert the user that they really shouldn't be doing what they did. At some level I also don't want to make "user manually modifies files inside juliaup" a supported scenario, and this PR kind of goes into that direction.

I think there is a bigger question whether we should move away from this config file design a bit and instead of tracking in the config file which versions are exactly installed, just look at the file system for that info. But that would be a much bigger change.

[DilumAluthge]

Can we store (in the Juliaup config file) the hash that we expect? Then we can compute the hash, and if the expected hash (stored in the Juliaup config file) does not match the observed computed hash (obtained by computing the treehash of the directory we have on disk), then we know things are broken, and we automate the process of fixing (e.g. delete the old broken directory and redownload/reextract, or whatever the correct fix is).

[davidanthoff]

Yeah, I like the idea of adding a hash to the config file that allows us to detect whether someone modified a installed Julia folder. Only caveat is I'm not sure whether there are situations where Julia might write into the Julia folder? If I run something with coverage on, for example, are there maybe files written etc? Just not sure.

But that is also just an orthogonal question to what this PR here does, i.e. the question what should happen when we detect a mismatch.