Gabriel Scherer

(cc @thierry-martinez)

The proposed syntax is okay, and with the `type%import` version it is actually nicer than the current syntax. However I don't understand how `[@@deriving]` directives would be handled with this...

> From what I understand, extension nodes are meant to be expanded (as nodes), not to expand the rest of the tree. Outside ppxlib, there are no strict requirements on...

> For performance and for predictability, extension nodes ideally don't leak outside their original AST placement unless it's in their nature to do so. It is not in the nature...

I cannot reproduce the issue with ocaml.4.07.1, ppx_deriving.4.2.1 and ppx_import.1.6. The reproduction command I use is ```shell ocamlfind ocamlc -package ppx_import -package ppx_deriving.std -dsource -c mod.ml ```

Looking at `_build/log`, the problem arises when calling `ocamldep` to compute `foo.ml.d`; your usage pattern (depending on the same module being compiled) can only work if `foo.cmi` is already built...

Thanks for noticing the ocamldep special case, I hadn't seen that indeed. (I linked the issue to the build system because manual testing doesn't call `ocamldep` at all, and works...

I agree the current state is not optimal; you were involved in the discussion to switch to the typer in ppx_import to avoid namespaces/module-aliases issue, and we collectively didn't see...

But we still have the problem of what to do during the dependency-computation phase, where we don't yet have the typing environment at hand (at least given the current structure;...

In the short term I wonder if there is something we (I?) should do for ppx_deriving as it exists. Hard-coding a special path for ocamldep sounds like the pragmatic approach,...