Closed bikallem closed 3 years ago
Using this PPX after this change is now more complicated, and it looks like there's a weird interaction between the PPX and the I/O runtime libs.
I am now required to open one of them before using the PPX, in order to bring some module in scope. IMO it looks like implicit magic and it's gonna make this very cumbersome to use.
I am now required to open one of them before using the PPX, in order to bring some module in scope. IMO it looks like implicit magic and it's gonna make this very cumbersome to use.
@anmonteiro Thanks for the feedback. I have pushed a commit to address the cumbersome part. One doesn't need to do open Ppx_rapper_lwt
or open Ppx_rapper_async
to use ppx_rapper
now. For the implicit part, before this PR lwt
and caqti-lwt
was always in implicit scope. Now, both those libs are in implicit scope only if they use ppx_rapper_lwt
. Similarly, when using ppx_rapper_async
, async
and caqti-async
are in implicit scope.
Thanks, this looks great! I will try to merge and release later this week.
Apologies for the late feedback -- I only got to try this now.
I'm glad we could avoid the problem of having to open the runtime library upon usage of the PPX. What still felt a little weird just now was having to add both ppx_rapper.runtime
and ppx_rapper_lwt
to the libraries section of my dune file. I feel like we could probably do better here. Any suggestions?
@anmonteiro I agree. The lwt and async libraries depend on ppx_rapper.runtime
so you should be able to just directly depend on ppx_rapper_async/lwt
I think, as in the examples.
Summary of the PR, fixes #10
async
andlwt
ppx_rapper_async
andppx_rapper_lwt
forasync
andlwt
respectivelyRapper.Make_helper
. This is the generalised functionality which enablesrapper
to support bothlwt
andasync
examples/async
forasync
usage example. Corollarily, theexamples/lwt
folder to holdlwt
usage example.Rapper_helper
module.