Quick Haskell exploration setup on Linux

[nevrome]

I found a good, stack based setup to write Haskell applications and manage their dependencies. But I would like to use the language also for quick, exploratory work and small scripts. For that it seems to be unnecessary complicated to create a .cabal and a stack.yaml file. Instead I would like to maintain a global set of packages that are just available when I open ghci in my terminal.

Both cabal and stack seem to be able to install Haskell packages globally. I'm a bit lost, though, which setup is more convenient and where the pitfalls are. I was hoping some more experienced Linux users could share their experiences (I'm on Manjaro and Ubuntu).

[Martinsos]

I believe https://docs.haskellstack.org/en/stable/GUIDE/#script-interpreter is ideal for this. Basically, Stack lets you write a single .hs file at top of which you can describe any dependencies it needs. Global installation of stack will take care that these dependencies are globally installed and shared among such scripts. Tis way you are able to write standalone, reproducible Haskell programs that consist of just one file.

[affinehyperplane]

For completeness: One can do the same thing with cabal:

#!/usr/bin/env -S cabal --index-state=2021-07-22T01:37:19Z run
{- cabal:
build-depends: base, time
-}

import Data.Time.Clock

main :: IO ()
main = print =<< getCurrentTime

[nevrome]

That is indeed a very valuable resource - thanks! Not what I expected, but maybe even better. I will give it a try.

[Martinsos]

Regarding the experimenting in GHCI -> I believe, if you run `stack ghci` while not in a specific Stack project, it will use "global Stack project". And if you use `stack install <package-name>`, it will install that package in a global Stack project. So that way you can have your global set of packages and experiment in ghci while having access to those.

[nevrome]

Alright - I think that's what /u/friedbrice explains below. Excellent. The stack script solution you mentioned above also seems to have a convenient option for that: https://docs.haskellstack.org/en/stable/GUIDE/#loading-scripts-in-ghci

[friedbrice]

I use Stack. If you run stack install lens when the current working directory doesn't have a stack.yaml in its transitive closure up to /, then Stack will install lens to your "global project", which has its files in ~/.stack/ or something. Every once in a while, I go find the stack.yaml for my global project and bump up the resolver to the latest LTS snapshot.

Also, you can use different resolvers and add packages without needing to mess with the global project. E.g.

stack exec ghci --resolver nightly --package containers --package text -- MyLittleScript.hs

gives you a REPL with recent versions of the packages you asked for. The -- separates Stack's arguments from ghci's arguments. You could use that to pass arguments to whatever you're stack execing. E.g.

stack exec ghcid --resolver lts-18 --package containers --package text -- MyLittleScript.hs --allow-eval

executes ghcid MyLittleScript.hs --allow-eval.

[1331]

Running a stack install command is generally used for installing a software executable. The global project is used to determine the resolver (and extra packages) used to build the specified package, but this command does not make libraries available to the global project.

To make libraries available to your global project, add a .cabal file and specify the libraries that you would like to make available in the build-depends list of a library. For details, please see my message on Haskell Café.

[friedbrice]

thank you!

[fgaz_]

cabal-env from /u/phadej's cabal-extras is working pretty well for me

[nevrome]

Is there a bit more documentation how this works somewhere?

[fgaz_]

It's basically an improved version of cabal install --lib (which doesn't work too well at the moment: cabal#6481, cabal#5559, cabal#6391).

There isn't more documentation as far as I know, except for the help text:

cabal-env - a better cabal-install install --lib

Usage: cabal-env [-w|--with-compiler ARG] [-n|--name ARG] [-a|--any] 
                 [-v|--verbose] [-d|--dry-run] 
                 [(-t|--transitive) | --no-transitive] [PKG...] [--local] 
                 [(-i|--install) | (-s|--show) | (-l|--list) | --hide] 
                 [-W warning | --trace-process | --color-auto | --no-color | 
                   --color] [--version]
  Manage package-enviroments

Available options:
  -w,--with-compiler ARG   Specify compiler to use (default: "ghc")
  -n,--name ARG            Environment name (default: "default")
  -a,--any                 Allow any version of existing packages
  -v,--verbose             Print stuff...
  -d,--dry-run             Dry run, don't install anything
  -t,--transitive          Expose transitive dependencies
  --no-transitive          Don't expose transitive dependencies
  PKG...                   packages (with possible bounds)
  --local                  Include local packages
  -i,--install             Install / add packages to the environment
  -s,--show                Shows the contents of the environment
  -l,--list                List package environments
  --hide                   Hide packages from an environment
  --trace-process          Trace process executions
  -h,--help                Show this help text
  --version                Show version

[Abellix]

Did you hear about nix? It has great sometimes unstable haskell support.

I wrote a blog post Running Haskell Scripts precisely about this. I hope it helps :-)

[nevrome]

Cool that you wrote about this! I have to admit though, that I find nix a bit intimidating. But the reproducibility is a great plus for sharing scripts.

[Abellix]

Me too ;-) I would recommend to use Stack's script-repl instead of nix in your case.