Add Deriving.find

[sim642]

This is a redo of #124 which follows the suggestion from #124 (comment).

[NathanReb]

Thanks for contributing to ppxlib!

Could you please give a bit of context? What are you planning to do with this? Is it only the alias use case mentioned in #124 ?

If that's the only use case, I'd be more in favor of referring to said deriver directly by linking it. Having this kind of feature is quite error prone as one could totally use it without declaring the dependency over the deriving plugin it's meant to reference, leading to crashing drivers.

[sim642]

It's the same alias use case, yes.

The intention would be that the ppx deriver which uses this feature to define an alias, would declare the other ppx deriver as a (dune) dependency as well. If one forgets that, it will be very obvious because the preprocessor would crash (just like it crashes when multiple derivers for the same name are linked, etc).

Of course Deriving.find would be avoidable, if all derivers just exposed their Deriving.t in the interface, but that's very rare I think. In part because ppxlib directs people to do that if they don't define aliases in the same deriver to begin with:

ppxlib/src/deriving.mli

Lines 148 to 151 in 75c507a

	val ignore : t -> unit
	(** Ignore a deriver. So that one can write:
	[Deriving.add ... |>
	Deriving.ignore] *)

Others (e.g., ppx_deriving_yojson) declare an empty interface.

[NathanReb]

The intention would be that the ppx deriver which uses this feature to define an alias, would declare the other ppx deriver as a (dune) dependency as well. If one forgets that, it will be very obvious because the preprocessor would crash

I agree that in theory, any cautious dev wouldn't omit this because it wouldn't survive testing but it is still permitted to write such code and have it build without declaring the dependency.

Some of the Janestreet derivers seem to expose the declared derivers, we could hint towards doing so for that specific purpose.

We can also try and patch the ones you would like to alias. Which one do you intend to use that way?

[sim642]

We can also try and patch the ones you would like to alias. Which one do you intend to use that way?

I think the ppx_deriving ones an ppx_deriving_yojson.

I would be for patching them to expose the derivers. Although I think Ppxlib.Deriving.ignore should then maybe be discouraged, in favor of exposing for reuse (not necessarily deprecated at this point though).

I agree that in theory, any cautious dev wouldn't omit this because it wouldn't survive testing but it is still permitted to write such code and have it build without declaring the dependency.

It's been a while since I tried this, but if I remember correctly, dune's ppx_runtime_deps on the deriver library with aliases needs to duplicate the runtime dependencies of all of the other derivers it declares as library dependencies for them to actually be included. If that's still the case, it's a much bigger pitfall.

[NathanReb]

I do expect that you will have to redefine the ppx_runtime_deps yeah, I'll take a look and will let you know!

[NathanReb]

In the meantime I'll also open PRs to expose ppx_deriving_yojson and ppx_deriving.std derivers!

[NathanReb]

I'm closing this as we decided to instead expose the relevant Deriving.t !