shake install with cabal shouldn't depend on having stack installed

[jneira]

• Currently running the shake install with cabal needs stack to get the symlink-bindir/installdir

• We can't simply fallback to the value in global cabal config cause install needs it to copy hie executables prefixed with versions and afaik there is no a simple way to get the actual value of symlink-bindir/installdir from global cabal config

• A possible solution would be fallback to a relative to cwd ./bin path but it will make users to copy manually the executables to the final location

• Another solution would be add options to shake install to let users do somethink like cabal v2-run install.hs -- hie-8.6.5 --cabal-options="--installdir=path"

  • It would be a improvement itself but it would add complexity to build

//cc @power-fungus

[samuelpilz]

Everyone wants this feature for a long time, including myself. I still cannot believe that cabal is unable to tell us its install-dir. Can someone reasonably familiar with cabal-install confirm that this is indeed not possible?

As far as I understand the current situation, the symlink-bindir is used to be able to rename the generated executable hie into hie-x.y. When we have no idea where it was installed, we cannot do the renaming. Can we get the directory hie was just installed to in any other way?

I am in favor of any approach that makes the situation better, however, we should be careful when adding non-trivial extra steps to the install-process. This might be necessary, but should not be taken lightly

[jneira]

Oh, i've forgotten to mention the better (?) solution: make three calls to cabal v2-install:

• cabal v2-install exe:hie
• cabal v2-install exe:hie --program-suffix=-8.6
• cabal v2-install exe:hie --program-suffix=-8.6.5

But cabal v2-install doesn't honour it for version 3.0.0.0, we would have to wait for @fendor pr to fix it and we only could remove the dependency for cabal versions including the fix.
Not sure if it will work with symlinks though 🤔

[fendor]

yes, this will hopefully remove the problem altogether. However, depending on how many versions of cabal-install we'd like to support, a work around might be necessary for previous versions.

[jneira]

Can someone reasonably familiar with cabal-install confirm that this is indeed not possible?

Well it think it is in ./dist-newstyle/cache/config so we could make a cabal v2-config and parse that file (if possible) copying the cabal code. An ugly hack... 😟
Not sure if there is a relatively lightweight package or executable that already does it... to investigate

[samuelpilz]

Using program-suffix would be my preferred solution. Only dropping the stack dependency for cabal that honors this option seems good enough for me. Or maybe someone could make a pr to add an option to get cabal's global install-dir, which would be the optimal solution

[samuelpilz]

Alternatively, we could replace the call to stack path --local-bindir to a hardcoded dir $HOME/.local/bin on unix and something else on windows. I do not know how desirable this is, but it sounds like a pragmatic solution

[jneira]

Alternatively, we could replace the call to stack path --local-bindir to a hardcoded dir $HOME/.local/bin on unix and something else on windows

Yeah, i think it is not worse that use stack one. Not sure if it is much better than installing in a relative dir ./bin though. I any case we must show to users where the binaries are installed to make easy move them or add the path to $PATH.

OTOH, I think there is not a path in windows for installing binaries that always is in %PATH% (%SYSTEMROOT%\System32 apart 😄)

[NickSeagull]

I think a possible solution would be %APPDATA%/hie, and add that to the PATH variable afterwards

[samuelpilz]

Where does stack path --local-bindir point to? We could use that as inspiration for the fixed path.

[jneira]

In windows is %APPDATA%\local\bin, but it is not a common one and there is not in %PATH% by default.
stack checks if it is in %PATH% and warns if it is not.

and add that to the PATH variable afterwards

Change it would depend on user rights and i bet there would be problems, so maybe stack chose that solution for that reason.

[mpickering]

We really shouldn't mess around with a user's PATH variable.

[samuelpilz]

I think we could mirror the approach from stack but implementing it manually:

• write to %APPDATA%\local\bin
• warn if it is not in the user's path

Out of curiosity, where does cabal (v2-)install put its binaries and how does the path-stuff get managed there?

[jneira]

In windows it uses installdir and throws an error if it is not defined in cabal global config or as cli option:

cabal.exe: installdir is not defined. Set it in your cabal config file or use
--installdir=<path>

(like in linux, right?)

[samuelpilz]

my global config is $HOME/.cabal and the binaries are installed in $HOME/.cabal/bin. I do not think this is configured somewhere in a config-file (on my system)

[fendor]

@power-fungus it is configured in $HOME/.cabal/config

[jneira]

Related cabal issue: haskell/cabal#5973

[fendor]

@jneira hvr told me today of https://hackage.haskell.org/package/cabal-install-parsers-0.2/ which would eliminate our usage of stack, imo. e.g. https://hackage.haskell.org/package/cabal-install-parsers-0.2/docs/Cabal-Config.html#t:Config

[jneira]

That is a promising path, although i am a little bit worried by the package dependency Cabal >=3.0.0.0 && <3.1.
We can try to follow to see if it causes any issue.

[fendor]

Yeah, that is worrisome. But we are demanding that for windows already... so... eh? Could also do a CPP instruction to support both, somewhat.