Consider implementing a way of specifying environment variables for cradles

[expipiplus1]

An example use case would be implementing nix support by provisioning relevant environment variables (NIX_*, HIE_HOOGLE_DATABASE and PATH (for finding ghc and other programs)) by running nix-shell --run env.

Although I don't use it, I suppose that anyone using direnv might find this useful too.

Ideally this would be a property on each cradle, with the child cradles in a multi cradle inheriting these variables unless they themselves specify this property.

Analogous to the bios and direct cradles perhaps one should be able to specify the environment variables via program or inline in the cradle.

This would make adding default.nix or shell.nix to the dependencies field in hie.yaml actually useful!

[fendor]

Would a format such as

cradle:
  cabal:
dependencies: []
environment:
  - name: HOOGLE_DATABASE
    value: "~/.hoogle"

be helpful?

Potential CradleAction type:

data CradleAction a = CradleAction {
                      actionName :: ActionName a
                      -- ^ Name of the action.
                      , runCradle :: LoggingFunction -> FilePath -> IO (CradleLoadResult ComponentOptions)
                      -- ^ Options to compile the given file with.
                      , environment :: [(String, String)]
                      }
  deriving (Functor)

This encoding would force the user to correctly set-up the environment for runCradle. However, it allows them to change them as needed programmatically.

cc @mpickering

[expipiplus1]

IIRC nix sets up four NIX_* variables for Haskell alone, then there is HIE_HOOGLE_DATABASE, not to mention the variables for correctly compiling C programs. I think having to specify the variable name in the cradle config might be a little onerous. A way to specify them wholesale (like the arguments program) would be necessary to make this useful with nix

[mpickering]

It's not clear to me we should be getting involved in this. Needs more motivation I think before attempting to fix something.

[expipiplus1]

My specific motivation was:

I currently have my editor call nix-shell --run 'hie -blah -blah'. However this does not respond to changes in the dependencies of the current project, i.e. I change package.yaml to add a dependency on the package foo and hie responds and tries to reload things, but because foo was not provisioned by nix-shell when I started my editor, ghc is no longer able to find it.

If however we could have hie get the environment variables 'live' then once package.yaml was updated, hie would reload things and call nix-shell --run env, getting pointed to a new package database and being able to find foo. At the moment I have to restart hie in my editor when I add a new package. This certainly isn't a massive issue, but I think that allowing hie.yaml to specify the environment in which ghc is run as well as flags is a sensible thing to do.

To summarize: The environment in which my project compiles is not static as the project is being written, it would be nice if hie-bios could cope with this.

I believe this would be a more generic solution for nix support than what's was proposed in #25, @domenkozar, what are your thoughts?

[expipiplus1]

@fendor mentions here https://github.com/alanz/vscode-hie-server/issues/233 that HLS and ghcide reload the session when package.yaml changes, but unless they also reenter the nix-shell (or update the right env variables) the requisite packages won't be available.

[cdsmith]

Here's some extra motivation. I'm trying to get HLS working for a nix-based build system, where some source files look something like this:

{-# OPTIONS_GHC -F -pgmF foo #-}

However, foo is not in the path when running haskell-language-server. I know the PATH during the program that's run by the bios cradle. I can even know it statically (by setting up the right symlink during the bios cradle). But I don't know how to add it to the PATH that runs HLS without telling everyone who works on the code to go change their editor configuration for this one project.

[cdsmith]

@mpickering @fendor If I wanted to work on this, do you have a sense for whether hie-bios would be interested in a pull request to add the functionality?

[fendor]

Yes, we are definitely interested in a proper solution!