If I want to include a DslPlugin in a pod, for types in that pod, and if it is used by code being built for the pod (test cases or otherwise), the compiler right now doesn't cope. It ought to manage circular dependencies with plugins the same as for other code. That also means that an updated plugin ought to run the updated version when compiling the other code.

I imagine it gets tricky, but I think this should be worked out.

It would also be nice to have separate compile-time vs. run-time dependencies in build,fan. (I haven't reviewed the docs just now, so I apologize if that's already there.) Maybe a separately specified dir for code needed for compiler plugin src, too.

Sorry for mixing up several issues here (using new plugins at build time for the same pod, compile vs. run time dependencies, and separate plugin src dir), but I think they might all be related. Maybe other issues I've missed, too.

I suppose I could have a separate pod for the plugin today (and does that resolve all my issues above?), but I'd be sad to have to request users to install multiple pods. Maybe not as big a deal with some kind of auto-install perhaps, but that can have its own woes ...

What do you think on all this, and how do you address it for the DSLs you have so far?

You can declare the anchor type in the same pod as the DslPlugin. But you can't actually use the DSL in the pod which is the compiler. That seems pretty sane to me, otherwise it becomes a bootstrap nightmare. In the case of tests, you can write your tests like I write my compiler tests (invoke the compiler at runtime against a string), or move the tests to another pod. Any sophisticated DslPlugin will probably need to use the compiler test model if you want to test for error checking.

In the case of tests, you can write your tests like I write my compiler tests (invoke the compiler at runtime against a string), or move the tests to another pod.

Thanks for the tips.

Any chance still of specifying compile-time vs. run-time dependencies? That is, using my pod should cause a run-time dependency on "compiler" for other folks, but I have to specify "compiler" as a dependency. It should only be needed for them when they actually compile.

Well, and maybe it would be needed for unit tests, too, if the unit tests use the compiler.

Any chance still of specifying compile-time vs. run-time dependencies?

I can see value in that, but seems hard to justify the extra complexity when you can just break the pod into two pods.

Edit: also note that compiler will probably always be present in a Fan system

I can see value in that, but seems hard to justify the extra complexity when you can just break the pod into two pods.

Except the person making their own new code would still have to claim a dependency on the DSL pod, so they retain an artificial run-time dependency.

Edit: also note that compiler will probably always be present in a Fan system

Does seem likely, I guess. I won't worry about it for now. Thanks.