Cleanup executables from old releases

[WorldSEnder]

The current output of ls -lh on the globalStoragePath directory produces for me

-rwxr--r-- 1 u u 114M 29. Jul 20:52 haskell-language-server-0.2.2-linux-8.8.3
-rwxr--r-- 1 u u 116M 30. Jul 02:52 haskell-language-server-0.2.2-linux-8.10.1
-rwxr--r-- 1 u u 122M 11. Aug 07:45 haskell-language-server-0.3.0-linux-8.8.3
-rwxr--r-- 1 u u 123M 11. Aug 07:50 haskell-language-server-0.3.0-linux-8.10.1
-rwxr--r-- 1 u u 4,8M 11. Aug 07:45 haskell-language-server-wrapper-0.3.0-linux
-rwxr--r-- 1 u u 4,8M 29. Jul 20:52 haskell-language-server-wrapper-0.2.2-linux

As can be seen, old releases of haskell-language-server, that will never be required again, are just taking up a decent amount of diskspace (~240MB), that will only get worse over time. There should be a policy to remove any older versions of the wrapper, perhaps when downloading a newer one.

[leiftw]

Had not found this when opening #346 (which refers to Windows, the folder content is slightly different).
I second this. Nobody needs more applications that waste gigabytes per year!

[jneira]

@lylek suggested here:

May I humbly suggest a menu item to purge all versions except the one(s) being used in open workspaces? That way folks don't have to know the path where they're stored. They can just, maybe once a year, run the cleanup option. And if it deletes a version they need for some workspace they don't have open - no big deal, it will re-download that version when they open it.

[jneira]

I've changed the title to Cleanup executables from older releases as afaiu the extension will not use older version of the hls executable itself.

Automatic deleting files is a delicate operation that can fail due to multiple reasons, even if the user has permissions to do it. We should ask users before doing it and handle the possible error.
Otoh maybe users dont want delete them, in case the new one breaks something and they want to disable automatic download and use a previous one. We should add a config option to control what to do and defaulting it to not do the automatic delete, just in case.

What about warn about the existence of older versions in globalStoragePath after dowloading a new version, mentioning the path to help user deleting manually the files they dont want? It would be a simpler and safer approach.

[lylek]

I think many people would be annoyed if it warned them about older versions every time they installed a new version. It would make them feel like they did something wrong.

How about this: Give an option to clean up old versions. But instead of automatically cleaning up all old versions or all versions not used by open workspaces, show a dialog box with a list of all the old versions found. Each row should clearly indicate what GHC and HLS versions are involved. It would be sorted in reverse order first by GHC version, then by HLS version. Each would have a check box to indicate that it should be purged. There would also be a checkbox to "delete all old versions" that would automatically check all the other boxes. Then there would be a button "Delete Selected Versions" to commit the operation.

Also it occurred to me that probably nobody wants to keep around two versions that are different versions of HLS for the same version of GHC. The focus is on keeping around versions for older GHCs that you might still be using. So if you have two binaries that are for different versions of HLS but the same version of GHC, you should probably just keep the newest one.

[cptwunderlich]

I would also suggest to simply delete older HLS versions. Optionally, one could add a config option "keep n old versions".
I just discovered this by chance and saw that I have 17 versions of HLS lying around...

[jneira]

It worths to note that due to deprecation of ghc support in haskell-language-server, new versions of the server might not support some ghc versions. Keep old versions of hls with support for those deprecated ghc's could help to neing able to load actual projects.
Although we aim to donwload automatically those hls versions: #454

[cptwunderlich]

I would say, when vscode-haskell downloads a new HLS version for GHC xyz, then it can delete the old HLS version for GHC xyz.
So, when the user upgrades GHC, this may leave one old HLS version per old GHC version, but at least we don't have 10 HLS' with the same GHC version.
(Or maybe keep 2 version per GHC version, if the new HLS is broken as a fallback?)

You can then add an Extension command to open the folder for manual cleaning, or something similar.

[jneira]

Last version of the extension has support for download/use older version of hls it they supports the ghc required for the project loaded. That is a nice feature but if makes more complex an eventuak automatic cleaning. It will download again the appropiate hls though.

[fendor]

Old executables can now be cleaned up by using ghcup. No further actions required here.