[@@deriving_inline] requires deriver to be present during non-lint build

[sim642]

The documentation states the following about [@@deriving_inline]:

ppxlib/doc/ppx-for-end-users.rst

Lines 77 to 83 in 9360b0c

	You might notice that the resulting file when using
	``[@@deriving_inline]`` needs no special treatment to be compiled. In
	particular, you can build it without the ppx rewriter or even
	ppxlib. You only need them while developing the project, in order to
	automatically produce the generated code but that's it. End users of
	your project do not need to install ppxlib and other ppx rewriters
	themselves.

However, this appears not to be true, as I observed by doing the following:

1. Added [@@deriving_inline yaml][@@@end] after a type declaration.
2. Added (lint (pps ppx_deriving_yaml)) into the dune file.
3. Ran dune build @lint --auto-promote, which did promote the inline implementations.
4. Ran dune build, which fails with the following:

   10 |   [@@deriving_inline yaml]
                             ^^^^
   Error: Ppxlib.Deriving: 'yaml' is not a supported type deriving generator
   

It appears to me that ppxlib is still trying to run the deriver for [@@deriving_inline] when there's already an implementation present (which I guess makes sense for round-trip checking, #338), but does so even when that deriver was only active for linting and not the normal build.
This defeats the claim of being able to drop dependencies for ppx-s, since for the normal build to succeed, I still need that deriver also in dune's (preprocess (pps ...)).

Or maybe I'm trying to use [@@deriving_inline] in an unusual way: to drop some deriver dependencies, but not all (so still have others present). The motivation for doing that is to use an unreleased version of the deriver (using opam pin) in a package that is to be released on opam (where it cannot have pins) without being forced to wait for the ppx's release.

[ceastlund]

I think @@deriving_inline only "needs no special treatment" when ppxlib is not run at all. Once you start preprocessing, ppxlib is going to want to know how to expand that inline code.

It's possible there should be a flag to tell ppxlib to only bother with @@deriving_inline during linting, to allow this kind of piecemeal use of it. But it sounds like your use case is pretty niche, so I'm not sure how much this is likely to be prioritized.

A pull request adding some straightforward flag like that would be welcome, certainly.

[mbarbin]

I wanted to comment on this issue because I found myself with a use case quite similar to what is described by @sim642 here (contemplating how to remove compile time dependency to ppx-es in some projects, outside of dev-mode).

If @@deriving_inline cannot be used to limit your ppx dependencies that way, what is it currently used for? (I'm curious).

If work in this area is still welcome, I'd be interested in learning more. I think I could consider allocating time on this, perhaps contributing to the manual, and/or try adding support for extending what deriving_inline can be used for.

[mbarbin]

I published a concrete example of what I'm trying to do here.

Edit: In particular the diff in this commit shows the error triggered if I add ppx_compare to the linters but not to the preprocessors list, and then try to use deriving_inline.