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

[sim642]

The documentation states the following about [@@deriving_inline]: https://github.com/ocaml-ppx/ppxlib/blob/9360b0c367ab5798895628bbb768e8685bdcb42f/doc/ppx-for-end-users.rst#L77-L83

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.