Hi @snoyberg (or anyone else who might have input), I have a question about using RIO. I have an application that first needs to load some config files and do some transformation of them. I'd like to store the config file data in the RIO environment (App), but that means I can't populate the App and call runRIO until I've collected that config data.
Unfortunately that means that if I encounter errors in the config file data, I can't call logError, etc., since I'm not yet in the RIO monad. This seems like a sort of chicken-and-egg problem.
Is the appropriate solution to bootstrap by using App types and separate phases of runRIO? E.g, create a Bootstrap datatype for the phase where it's loading the config files. It would already be set up with a logger and process context. Once that is done and has loaded the config data, that call to runRIO would return a Config structure. Then I'd have an App type which included everything from Bootstrap plus the Config data, and I'd do a second call to runRIO.
Only thing is, it seems like a bit of redundant boilerplate to have to create two similar data types, Bootstrap and App, where App just has one additional field.
Is there a more canonical way of handling this?
docs https://docs.haskellstack.org/en/stable/nix_integration/ are still saying
When using the Nix integration, Haskell dependencies are handled as usual: They are downloaded from Stackage and built locally by Stack. Nix is used by Stack to provide the non-Haskell dependencies needed by these Haskell packages.