hrepl doesn't expose dependencies by default. To load a dependency into the
interpreter, it needs to be either passed explicitly on the command line, or else
exposed with :set -package .... This could be considered "working as intended"
since it's how the actual Bazel build rules work. However, it's not a great user experience:
The ... may be a mangled GHC package name
:set -package causes all modules to reload and makes you lose all bindinsg.
The current recommended approach is to use --package //some:label which will add the given target as an exposed (compiled) dependency. But in all cases, if you want to expose
a new dependency you effectively need to start a new session.
Google's internal version of hrepl exposes everything, but that has its own tradeoff: Two
modules from different targets could conflict, and distinguishing between them with
-XPackageImports is cumbersome due to the mangled package names. Internally, we
modified GHC to be more permissive and allow unmangled labels as package names.
hrepldoesn't expose dependencies by default. To load a dependency into the interpreter, it needs to be either passed explicitly on the command line, or else exposed with:set -package .... This could be considered "working as intended" since it's how the actual Bazel build rules work. However, it's not a great user experience:...may be a mangled GHC package name:set -packagecauses all modules to reload and makes you lose all bindinsg.The current recommended approach is to use
--package //some:labelwhich will add the given target as an exposed (compiled) dependency. But in all cases, if you want to expose a new dependency you effectively need to start a new session.Google's internal version of hrepl exposes everything, but that has its own tradeoff: Two modules from different targets could conflict, and distinguishing between them with
-XPackageImportsis cumbersome due to the mangled package names. Internally, we modified GHC to be more permissive and allow unmangled labels as package names.