Multi-component REPL

[robrix]

I have configured a bunch of different projects to use a script to load multiple components in ghcide. This is no longer necessary as the multi-component support in hie-bios is working beautifully! 💖 However, I also use these scripts to provide a multi-component REPL—to load ghci with the right search paths, warnings, etc. for the library, tests, and executables.

Unfortunately, maintaining these ghci-flags scripts is kind of a drag; I’d much rather configure hie-bios for multiple components (which I will do for editor integration anyway) and then ask it. However, hie-bios flags expects to be called with a source file, but I wouldn’t know that until I’m actually running in ghci, and even then, it’s not really how ghci works; it doesn’t use a different set of options per file.

I’m definitely ok with compromising there a little bit by e.g. swapping out the -outputdir—it’s what my scripts to return the flags do anyway—but it would be super convenient to get the configuration for each component from hie-bios with a single call rather than having to find or nominate a source file within each component and ask hie-bios for the flags for each one by one. Maybe the interface could be hie-bios flags without passing paths.

Is this something you’d consider supporting?

[fendor]

Hi, sorry for the very delayed response.

Can you elaborate what changes you would require? Changes to the cli are not a problem if it would help your use-case (no idea whether this is still relevant to you)

[robrix]

Still very much relevant 😊 I think a hie-bios flags command would be excellent, or alternatively a hie-bios repl command which launches ghci with the union of the flags for the various components hie-bios has been configured for. To be honest, I’d prefer the former, as it potentially serves other use cases as well, and gives me more latitude in passing extra flags to ghci to e.g. configure the RTS or load scripts. It also seems a little more in keeping with hie-bios’ design thus far.

So in brief, I’d aim for:

1. an hie-bios flags (or w/e name is preferred) command
2. which emits flags suitable for passing to ghci, one per line,
3. including paths for interface files, object files, sources, autogen’d files, headers, packages, warning flags, and so on,
4. for all cabal package components for which hie-bios has been configured (and therefore unioning multiple components’ flags, compromising as necessary to deal with mutually exclusive/contradictory flags), and
5. without requiring the caller to specify the paths to any individual source files like the usual hie-bios calls require.

For comparison, the scripts I’m using now are mostly copy-pasta after some initial configuration quite some time ago. Here’s an example:

https://github.com/robrix/sequoia/blob/main/script/ghci-flags

Since the union of flags includes some that would be mutually exclusive—AFAIK there’s no way to configure ghci to use a different -outputdir depending on the file path—I’ve made some compromises here worth noting:

• I define my own build dir (separate from, tho nearby cabal’s) so as to avoid stepping on cabal’s toes
• all components go into the same build dir
• therefore, I maintain the discipline that all modules loaded in the same repl shall have distinct module names
• I hardcode a number of things including the package name and version; hie-bios could probably do a better job of this in particular, tho the mutually exclusive values point applies to this as well

(Note that I do not intend to suggest that hie-bios should replicate my scripts behaviours precisely, merely that a number of these points will arise in anything attempting to load or enable loading of multiple components in a single ghci session due to limitations of ghci itself. For my purposes, if you can help me get a REPL up loading my library and exe and tests at once, without having to maintain these ridiculous scripts, I will be overjoyed!)

Thank you for the response, and thank you for hie-bios itself; it’s wonderful what it’s done for Haskell development ✨

[fendor]

Again, sorry for this delay!

In theory, I don't think this is a huge problem to implement, but I didn't have time for it recently.

If you want to give it a try, I could give some pointers on how to implement it.