when using cabal-install-3 to build xmonad, must add --lib

[jwaldmann]

This is more a matter of documentation. It cost me some time to debug, so I am noting it here:

If you built xmonad using cabal-install-3 (with default config file),
then ghci .xmonad/xmonad.hs, or xmonad --recompile, produces errors like

.xmonad/xmonad.hs:1:1: error:
    Could not load module ‘XMonad’
    It is a member of the hidden package ‘xmonad-0.15’.

The solution (?) is to un-hide the packages with cabal install --lib xmonad xmonad-contrib. Then ghc picks them up without any -package options.

It seems cabal-install v3 currently is under-documented (e.g., https://www.haskell.org/cabal/users-guide/# seems to refer to version 2.4)

[geekosaur]

The right way to use cabal-install in v2+ mode is probably a build script, not cabal install as such; stick to v1-install otherwise, as this will be only the start of the problems (as soon as there are external dependencies things will become more complex, for example).

[Memorytaco]

You could also manually add an entry to ghc environment file( which is usually located at ~/.ghc/{x86_64-linux-8.8.1}/environments/default. Try to find your specific location in your home directory.

This environment file acts like a reference file for installed package which is located in .cabal/store.

[jwaldmann]

Yes, cabal install --lib writes (adds) to the global env file.

But using the global env is not recommended. We can cabal install --lib --package-env=xmonad but then for xmonad --recompile to work: how does it know about this environment file?

Similar: tidalcycles/Tidal#572 . In fact, using the global env for both xmonad and tidal is not working for me (because of conflicting versions for dependencies)

[hvr]

@jwaldmann

But using the global env is not recommended. We can cabal install --lib --package-env=xmonad but then for xmonad --recompile to work: how does it know about this environment file?

That's actually not that hard; xmonad has support for a ~/.xmonad/build script which if present in the filesystem (& executable) will be used instead of the hard-wired ghc invocation (see

xmonad/src/XMonad/Core.hs

Lines 681 to 692 in c54e708

	compileGHC bin dir errHandle =
	runProcess "ghc" ["--make"
	, "xmonad.hs"
	, "-i"
	, "-ilib"
	, "-fforce-recomp"
	, "-main-is", "main"
	, "-v0"
	, "-o", bin
	] (Just dir) Nothing Nothing Nothing (Just errHandle)
	compileScript bin dir script errHandle =
	runProcess script [bin] (Just dir) Nothing Nothing Nothing (Just errHandle)

)

I have a .xmonad/build-script that looks like

#!/bin/sh -e

if [ "$#" != 1 ]; then
    >&2 echo "script called with wrong number of arguments"
    exit 2
fi

if [ ! -f ./xmonad.hs ]; then
    >&2 echo "xmonad.hs not found in current folder"
    exit 2
fi

set -x

rm -f xmonad.tmp xmonad.o xmonad.hi

ghc-8.8.3 --make -package-env=xmonad -i -ilib -fforce-recomp -main-is main -O -Wall -v0 xmonad.hs -o xmonad.tmp

rm -f xmonad.o xmonad.hi

strip xmonad.tmp

mv xmonad.tmp "$1"

The important bit is the -package-env=xmonad GHC flag.

---

PS: But actually, you don't even need a custom build script (unless as in my case, if I want to select a specific GHC version rather than whatever GHC version ghc on $PATH is pointing to); thanks to the CWD-style package-env feature of GHC you can also just construct a package-env file (matching your GHC's version) such as e.g.

~/.xmonad/.ghc.environment.x86_64-linux-8.8.3

file and then xmonad's default ghc-invocation will automatically pick it up.

...and to answer how to conveniently do this (works with at least cabal 3.2):

cabal install -z --lib --package-env=$HOME/.xmonad/ xmonad xmonad-contrib

This will automatically create a CWD-style GHC package env-file in ~/.xmonad/ named accordingly. You might want to rm the env-file if you into weird solver errors when trying to "install" additional libs into the environment. There's various possibilities and workflows possible how to manage env-files... :-)

[liskin]

Here's an idea: why don't we make xmonad capture the values of GHC_ENVIRONMENT and GHC_PACKAGE_PATH at the time it's being built, and reuse these when invoking ghc to rebuild the configuration? That should recreate the conditions in which xmonad was being built…

It's quite a hack, but is there a better way? xmonad was built in an era when a single global cabal hell^Wenvironment was the norm, so just invoking ghc --make xmonad.hs made sense, but these days most people use either stack or cabal v2-build and the default recompilation mechanism fails for most of them unless they manually set up a build script for xmonad. And that's just silly, terrible UX.

Would it work? Would it break?

[geekosaur]

It would work, but I suggest never touching it with cabal or stack again because they'll both be confused by it having changed out from under them. They both expect to have full control over things in their domain.

(Reportedly hvr is gone, so I don't expect a response from him.)

Oh, also you can't upgrade any dependencies this way because that will break stack/cabal.

[liskin]

On second (or maybe third? this has been on the back of my mind for a while) I feel that capturing these variables during build might be too much of a hack. Might be better to test if --package-env= works reliably across our users' cabal version and then make sure we recommend that everywhere (and yeah, we should consolidate our install instructions a bit, there's some in README.md, some in INSTALL.md, some on the download page of the website, some in the quickstart page of the website, and surely the wiki is filled with some as well).

And for stack, perhaps xmonad might actually learn to deal with that? The new install guide recommends placing stack.yaml in ~/.xmonad, so xmonad can detect that and use stack exec ghc. Possibly we can add stackYaml field to the config file.

It would work, but I suggest never touching it with cabal or stack again because they'll both be confused by it having changed out from under them. They both expect to have full control over things in their domain.

I think this is a misunderstanding. Setting GHC_ENVIRONMENT and GHC_PACKAGE_PATH will only make the xmonad and xmonad-contrib libraries available to ghc, which is then used to compile the xmonad.hs in ~/.xmonad/ that is outside of any cabal project. If you do have a cabal project there, then this doesn't apply to you, as you'll need a build script nevertheless.

[liskin]

(Reportedly hvr is gone, so I don't expect a response from him.)

I wasn't really expecting any reply from him. Just wanted to write up my thoughts and possibly gather feedback from other xmonad devs or users.

[geekosaur]

I think this is a misunderstanding. Setting GHC_ENVIRONMENT and GHC_PACKAGE_PATH will only make the xmonad and xmonad-contrib libraries available to ghc, which is then used to compile the xmonad.hs in ~/.xmonad/ that is outside of any cabal project. If you do have a cabal project there, then this doesn't apply to you, as you'll need a build script nevertheless.

Except it has to come from somewhere the first time.

[liskin]

Dyre detects stack.yaml next to the configuration file and uses it: https://github.com/willdonnelly/dyre/blob/master/CHANGELOG.md
Seems to also be somehow cabal-aware, although I haven't looked into details. We should either get inspired by Dyre or just use it (but the support for stack.yaml is quite new and isn't in any Stackage LTS, so we'd make it harder to install/package xmonad).

[liskin]

Note that the build instructions in INSTALL.md were updated in #314 and the website now also recommends --package-env. The only thing left is cleaning up the README! Any volunteers? :-)

[geekosaur]

And the wiki, sadly, which still recommends running Setup.hs. (At this point I'm more than half tempted to say burn the wiki down and start over.)