stack install.hs build-all installs cabal in $HOME/.local/bin

[alexanderkjeldaas]

I was a bit surprised that stack install.sh build-all installs a new cabal into $HOME/.local/bin. That seems to go a bit beyond what that command is supposed to do.

[fendor]

Would you prefer that the command fails if no appropriate cabal version can be found?

[samuelpilz]

Hopefully, this can be removed in the future, but currently the cabal Binary is a runtime dependency of hie

[fendor]

Still, instead of automatically installing a cabal version we need, it might be better to show an error message and let the user decide how to resolve the problem with cabal.

[jneira]

Another approach could be (optionally) download runtime dependencies at runtime, when precompiled binaries are available and the tool is not present in path or custom location (like stack does with ghc)

[samuelpilz]

I am against downloading dependencies at runtime since this increases startup-latency even further.

The current state is not pretty, but the current plugins do not allow a better solution. For this reason, I would like to close this issue.

[jneira]

I am against downloading dependencies at runtime since this increases startup-latency even further.

Mmm, totally agree with that, but if we want at some point offer hie as a precompiled binary itself (imho essential to increase the user base) we have to solve this anyway.

I think initiated haskell devs will have already cabal, usually in $PATH, so they will not have any latency. If we let customize cabal location, users could choose their fav cabal version suited for hie. Download cabal would be the last resort and should be notified to user, in a second plane and fail gracefully with no internet connection.

It actually is 40-70 Mb so i think the delay will not be terrible, right?

[fendor]

Well, on a 1Mbit/s connection that is already more than a minute. However, the bigger problem I see is, if you use an older cabal and a newer one on the same project, a lot of stuff breaks. E.g. the user uses the pre shipped with their distro cabal version 2.4 or something like that on their project with cabal v2-build. However, hie makes use of the latest and greatest development tools in haskell, thus it installs cabal 3.0.0.0, assuming it had been released already. The build - caches will have different contents and formats and ultimately cause a lot of package rebuilds and unforeseen breakage.
Possible solutions are to force every user of hie to use the same cabal version or be aware of already installed cabal versions and act accordingly.

[samuelpilz]

I hope for a more isolated deployment in the future. The hie-bios will open a lot of possibilities and the hlint data files would be a first step when I get around to them.

However, this is a non-trivial multi step process and has currently a blocker in most cases.

[jneira]

I see is, if you use an older cabal and a newer one on the same project, a lot of stuff breaks

Out of curiosity i've test switching cabal versions (2.4.1.0 <-> 3.0.0.0) building a package (lsp-test) with cabal v2-build and somewhat surprisingly the builds didn't fail. Cabal has to reindex hackage (and it takes a while) between builds but honours the packages already compiled and cached in the store.

Maybe switching between more distant versions or using v1-build or vX-sandbox could cause errors or inconsistencies, but we always could control the cabal build to isolate hie builds.

The caveat i am thinking now it is once you start to control a runtime dependency it is difficult to stop and cabal is a wild beast with lot of switches and its own runtime deps (f.e. ghc itself). So maybe the wiser option would be follow the @fendor's proposal:

• do not install cabal by default in the hie build
• inform the user at runtime that cabal is required when opening a project that really needs it, including a url to install it
• add a hie option to parametrize cabal location used by hie

[samuelpilz]

I see the merits of this proposal. However, I am strictly against implementing this approach.

• I would like to wait and see the implications of removing cabal-helper. Until that is done, the cost of a temporary solution is too large.
• nobody knows what does and what does not work if cabal-install is not found at runtime. Making it a "soft runtime-dependency" has unknown implications
• The installation process is still error-prone. Currently, I am still working on figuring out what can go wrong during installation and adding checks for that in the install-script. I fear the risk that adding an option to skip the installation of cabal-install will lead to countless errors when used incorrectly.
• The tests still fail on azure-ci since we cannot get the installation process right.
• cabal-install is not installed if it is already found in the path, so the issue is not too bad.

Maybe these are not the best arguments and I agree installing cabal-install is not a best-practive. But until the installation process and runtime-dependencies of hie are under control we cannot afford the luxury of this best-practice.

[jneira]

But until the installation process and runtime-dependencies of hie are under control we cannot afford the luxury of this best-practice.

fair enough, we can handle cabal later as part of other runtime deps, in the context of #1068

cabal-install is not installed if it is already found in the path, so the issue is not too bad.

mmm, it seems it is installed too if the version of the previous one doesnt match the required by hie (including if it is a newer one, i guess).

I think that maybe we should avoid overwrite the existing one and warn the user about the version mismatch and its consequences (or at least overwrite it but warn the user about it).

That was your case @alexanderkjeldaas? did you have a previous cabal installed with another version than 2.4.1.0?

[samuelpilz]

cabal-install is not installed if it is already found in the path, so the issue is not too bad.

mmm, it seems it is installed too if the version of the previous one doesnt match the required by hie (including if it is a newer one, i guess).

I think that maybe we should avoid overwrite the existing one and warn the user about the version mismatch and its consequences (or at least overwrite it but warn the user about it).

Fair enough. Currently, we overwrite a cabal-executable when its too old. When the stack version is too low, we abort. The same should happen for cabal

[samuelpilz]

should this issue be closed by #1344? This PR implements the changes as described in my previous comment (#1327 (comment))

[jneira]

@power-fungus imo that is the case, @alexanderkjeldaas could ask to reopen it is not.