Multi target haskell_repl

[aherrmann]

Closes #380

• Adds a new rule haskell_repl which constructs a ghci wrapper that loads multiple targets by source.
  Example usage

  haskell_repl(
      name = "my-repl",
      # Collect all transitive Haskell dependencies from these targets.
      deps = [
          "//package-a:target-1",
          "//package-b:target-2",
      ],
      # Load targets by source that match these patterns.
      include = [
          "//package-a/...",
          "//packaga-b/...",
          "//common/...",
      ],
      # Don't load targets by source that match these patterns.
      exclude = [
          "//package-a/vendored/...",
      ],
  )
  

  • Packages which are not loaded by source, will be loaded as compiled packages using -package-id, -package-db flags.
  • Prebuilt package dependencies are always loaded as -package.
  • Packages from external workspaces are never loaded by source, i.e. always as compiled packages.
  • All packages loaded by source contribute their compiler_flags and repl_ghci_flags.
  • Sets the RUNFILES_DIR environment variable, so that code that requires runfiles can be tested in the REPL.
• Modifies the pre-existing ghci_repl_wrapper.sh so it can be used for the multi target repl.

[SebastianKG]

Above is a problem I ran into when using this branch.

[aherrmann]

@SebastianKG Thanks for testing this. That commit is out-of-date with this PR. Could you retry on the current state of this PR (branch workspace_repl) with the following commands?

$ nix-shell --pure --run 'bazel run //tests/multi_repl:c_only_repl'
$ nix-shell --pure --run 'bazel run //tests/multi_repl:c_multi_repl'

It's surprising that the :add command lists no source files. This PR includes tests which load the REPLs that pass on CI.

[aherrmann]

Noticed an issue with the generated package-db flags in the repl wrapper. Those were relative to execution directory instead of the execroot, which could lead to missing package dbs. I've fixed it by making those paths relative to the execroot.

[SebastianKG]

Awesome, I gave it another look, and your latest code seems to load the correct modules. Great work!

[Profpatsch]

Impressive piece of code!

I am unsure about the include/exclude parsing though. It feels like we are leaving bazel here to do our own stuff, which is going to bite us because we can never implement exactly the same target logic that bazel implements.
If I remember correctly, there is a way to call bazel query from within bazel rules, via some builtin primitive. If its possible, we should use that at least. If not, we should open an upstream feature request describing our use-case and mark the attributes with an experimental- prefix for now (until we know whether there is going to be an upstream feature).

Regarding old-style @repl syntax, is this new way a superset of that? Then we could deprecate it.
There’s also haskell/private/actions/repl.bzl. Is that file used after this change or can we remove it?

[aherrmann]

@Profpatsch Thanks for the great comments. I've addressed them all PTAL.

[thufschmitt]

Awesome! 👍

(I'd like some of this to be merged with #757 at some point, but that's future work).

[thufschmitt]

Wouldn't it be possible to factor all this file out with the new haskell_repl rule?

[aherrmann]

Not quite at the moment. haskell_repl is its own rule and can return a DefaultInto and thereby properly use runfiles. haskell/private/actions/repl.bzl creates an extra output in the regular haskell_* rules and cannot return a dedicated DefaultInfo with runfiles. Instead it has to use the ln trick to force it's dependencies and refer to them in bazel-out.

I agree that there is duplication that we don't want to keep around in the long term. One possible way forward could be to drop haskell/private/actions/repl.bzl completely and replace it by the haskell/repl.bzl aspect, similar to haskell/haddock.bzl. But, I'd prefer to do that in a separate PR.

[Profpatsch]

Great, great work

[shmish111]

Love it!