I just created a dub package. Frankly, the whole thign is backward.

[Alexandru Ermicioi]

On Wednesday, 27 April 2022 at 14:37:35 UTC, H. S. Teoh wrote:
>> Dub is more like maven from java world. I.e. it uses 
>> declarative approach to define a project and how to build it.
>
> Why can't a plugin DSL be declarative too?

It can, I was just thinking that dub is more like maven in java 
world, and for some reason was thinking that you'd extend config 
syntax to plugins (which is wrong).

It would be worth to check if existing language can be employed 
instead of custom dsl. It should lessen the need of maintenance 
then. Perhaps interpreter for D, or javascript?

>> Code based config build systems in D are more like gradle, 
>> since gradle dsl is just plain groovy with some ast macros.
> [...]
>
> IMO, it's better to have a declarative language for writing 
> plugins, so that you do not have to recompile dub to install a 
> plugin.

That's where shared library jumps in, to avoid dub recompilation.
The idea is that dub once seeing that a project requires plugin 
x, will download it from official repo, and load it and let it 
run at right events. This though, means shared lib use should be 
without hiccups in D.

If shared lib hiccups are not fixed or avoided in dub, then 
following can be done for a plugin based system:
1. Complete recompile of dub for each project combination of 
plugins, in order to run them.
2. Some form of microservices where each plugin is a standalone 
process.
3. Use of a interpreted language, declarative or imperative (your 
proposal).

Personally I'd prefer plugins as shared libs, and a well defined 
api for dub core through which plugins could interact and perform 
their job, while for configuration being done through existing 
sdl and json formats.

It would still be interesting to see what you can come up with 
custom DSL :)