Re-running installer for helper binaries gives up

[begriffs]

The logic checks for a ~/.config/haskell-vim-now/hvn-helper-binaries/stack.yml, and if found considers the binaries to be built and skips further work. However if a previous installation was interrupted then this file will exist and the installer will never make the binaries.

https://github.com/begriffs/haskell-vim-now/blob/master/scripts/setup_haskell.hs#L130-L131

[jship]

Good point! What do you think of having some kind of "force helper binary install" flag or something?

By default, users wouldn't have to wait on them if they already have them installed, but if they specify the force flag, they will rebuild regardless of stack.yaml being there.

[begriffs]

Yeah, a force install flag would work. It could also check for the presence of the generated helper binaries rather than for the stack file.

[harendra-kumar]

1. A good strategy is to check whether the binaries exist at the install destination path (i.e. ~/.local/bin) and always reinstall those that do not exist and never install the ones that exist. If we overwrite existing binaries it might silently break the user's configuration. With this rule we do not need a separate flag to check whether to reinstall or not. But we can warn users about the binaries that were already found and were not reinstalled.

2. We should always remove the hvn-helper-binaries directory. Firstly, it is not needed, secondly it consumes a lot of space as well that we must reclaim:

cueball:~$ du -sm hvn-helper-binaries/
262	hvn-helper-binaries/

[begriffs]

Maybe the presence of the hvn-helper-binaries directory would speed up binary rebuilds? Otherwise we'd have to rebuild all those deps... But maybe rebuilding binaries happens so rarely that it's worth it to clear out that directory after a successful install. I'd take a pull request if you're interested in doing an rmtree on it.