[WIP]: Nix env support for the wrapper

[Anton-Latukha]

WIP to solving #493

IDEs are currently required to provide their own custom Nix env loading mechanism and wrapper for the haskell-language-server-wrapper.

Nix env load from first and second look seems pretty trivial to do.

What essentially needs to be done - is:
a) --nix <args> option to load Nix env and then load --lsp <args>
b) --nix <args> <all_other_keys> option to load Nix env with args and there language-server-wrapper <all_other_keys>.

Since wrapper exe is properly decoupled (does callProcess for main HLS exe) - so when --nix wrapper runs itselt inside Nix env: nix-shell . --command '<path_to>/haskell-language-server-wrapper <args>' as always.

[maralorn]

I have several comments.

1. I am not convinced this is a short coming of hls-wrapper. Fixing this here feels like a broken abstraction.
2. This implementation of the --nix flag seems to fail in a lot of cases. If you put that flag in your global editor config (which seems to me is the only place you can reasonably put it) hls will fail in all projects which don‘t have shell.nix or default.nix (or a broken one or if you open hls in a subdir of a project, or if you just open a quick Test.hs file to write a tiny example and therefor don‘t even have a project.)
3. If haskell-language-server-wrapper --nix is an alias for nix-shell . --command 'haskell-language-server-wrapper' then maybe users should put that into their editor config?

[Anton-Latukha]

@maralorn

Essentially, I read above as a clearly put a statement with the aim of blockage of any further work, without any room given for any consideration or discussion.

But the points put are easily debatable.

This is marked WIP for a reason, I invited here for the discussion and ideas.

So I am probably outta here then.

[maralorn]

@Anton-Latukha I am sorry. I definitely did not want to block your effort. And I am not in the position to. I am not a haskell-language-server developer, so this is totally not my decision. (That being said, in my experience they care a lot about separation of concerns.)

If they decide that automatically loading nix environments is a feature that belongs in the wrapper. By all means, please do that.

I hope with commenting on a WIP PR I have not hurt any etiquette. My intention was to have a discussion about this before you invest more work into it.

If the decision is to add this feature there are a few use cases to consider:

1. Should the wrapper load the nix-shell in a way, that it can load the hls binary out of the nix-shell?
2. How can the wrapper gracefully decide when to (try to) load the nix-shell and when not?
3. How does this interact with hie-bios? Would it maybe be another idea to have a nix cradle?

Of course we don‘t need answers to this questions to have this feature, but I wanted to mention them.

[Anton-Latukha]

Loading of Nix-shell actually straight-forward (pseudocode description):

if `--nix` requested && `nix-shell` executable available && (`shell.nix` || `default.nix` exist)
  then
    try
      Wrapper loads the env and launches itself classically inside it: `nix-shell . --command 'wrapper <args>'`
     `wrapper <args>` - run default case
    catch (if loading of env didn't worked)
      stdErr: Nix env loading was requested, but couldn't load Nix env OR start the HLS inside it - proceeding further the default way.
      `wrapper <args>` - run default case      
  else
    `wrapper <args>` - run default case

[Anton-Latukha]

Well, too many people came out and convinced me that direnv/lorri works well and I see that everyone keeps having the second thoughts about integrating reproducible envs for Haskell projects.

It was good to at least discuss it thou.