On Wed, Apr 27, 2022 at 08:14:21AM +0000, Alexandru Ermicioi via Digitalmars-d wrote:
> On Tuesday, 26 April 2022 at 20:30:59 UTC, H. S. Teoh wrote:
[...]
> > Why not expand dub's DSL to be able to encode the kind of functionality needed to write external plugins, then rewrite existing functionality in terms of that DSL as a plugin?  Then others can also write plugins in the same DSL, and you wouldn't need to recompile dub just to add a plugin.  Just download the plugin description file into some standard dub directory, and dub would pick it up upon startup.
> 
> 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?


> 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.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.

On Wednesday, 27 April 2022 at 11:09:33 UTC, Bastiaan Veelo wrote:
> Indeed, not native. Are you suggesting Dub should include winget?

If dub could resolve non-D dependencies, it could actually grab winget as part of its resolution. Potentially a very interesting angle.

On Wed, Apr 27, 2022 at 03:42:50PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Wednesday, 27 April 2022 at 11:09:33 UTC, Bastiaan Veelo wrote:
> > Indeed, not native. Are you suggesting Dub should include winget?
> 
> If dub could resolve non-D dependencies, it could actually grab winget as part of its resolution. Potentially a very interesting angle.

If dub could be expanded to accept a superset of its narrowminded interpretation of SemVer, its dependency resolution algorithm could be reused for resolving non-D dependencies too.  I think this is a fruitful direction to go.  Dub seriously needs to get over its walled garden mentality and become more open to interacting with the outside world.

This would most certainly lead to very interesting developments. The package management part of dub could be decoupled from the build system, for example, by making build systems part of the dependency system so that alternative build systems can be installed and used directly by dub.  Cross-language capability could be implemented by making compiler toolchains part of the dependency system -- you'd simply depend on, say, a C compiler or a Java compiler pseudo-package, and you could build native C/Java code directly inside dub and link it to D code (e.g., via jni.d as part of the Java compiler pseudo-package).

There's a whole world out there beyond the fences of the walled garden, just waiting to be explored.


T

-- 
The problem with the world is that everybody else is stupid.

On Wednesday, 27 April 2022 at 20:38:53 UTC, H. S. Teoh wrote:
> There's a whole world out there beyond the fences of the walled garden, just waiting to be explored.

Aye. I've written a bit in my blog about these ideas btw:

dub's problems and some general ideas for dub 2.0:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_03_28.html

a bit more thought on fallback dependencies and system integration:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_04_25.html


I think my topic next week might be more general, about how so many of the D stuff right now puts burden on library developers without benefiting them. Maintaining dub.json gives me absolutely nothing and is a bit of a pain to keep working. A lot of my views lately have just been reducing the cost - I already have a system that works really well, so I don't expect to benefit from any of these concepts. So I'm all about reducing the cost.

But there might be potential to actually give some return on investment if all this worked; I could make the postgres.d, for example, find a libpq or get the user to download it. (Though again, I kinda already can with runtime dynamic loading. But meh.)

The one time dub delivered a little was the android package and even there it limited me more than it benefited when compared to dmd -i. alas.

On Wednesday, 27 April 2022 at 20:38:53 UTC, H. S. Teoh wrote:
> [snip]
> This would most certainly lead to very interesting developments. The package management part of dub could be decoupled from the build system, for example, by making build systems part of the dependency system so that alternative build systems can be installed and used directly by dub.  [snip]

That's been talked about for awhile...maybe it would take someone forking dub and just releasing one or the other component.

On 28/04/2022 8:38 AM, H. S. Teoh wrote:
> If dub could be expanded to accept a superset of its narrowminded
> interpretation of SemVer, its dependency resolution algorithm could be
> reused for resolving non-D dependencies too.  I think this is a fruitful
> direction to go.  Dub seriously needs to get over its walled garden
> mentality and become more open to interacting with the outside world.

Dependency resolution algorithm specialization:

https://github.com/dlang/dub/blob/059f7a2a16cf7a50a5c68dc295c796482116ff87/source/dub/dub.d#L1793

Semver matching ext.

https://github.com/dlang/dub/blob/master/source/dub/dependency.d#L453

On Wed, Apr 27, 2022 at 10:20:23PM +0000, jmh530 via Digitalmars-d wrote:
> On Wednesday, 27 April 2022 at 20:38:53 UTC, H. S. Teoh wrote:
> > [snip]
> > This would most certainly lead to very interesting developments. The
> > package management part of dub could be decoupled from the build
> > system, for example, by making build systems part of the dependency
> > system so that alternative build systems can be installed and used
> > directly by dub.  [snip]
> 
> That's been talked about for awhile...maybe it would take someone forking dub and just releasing one or the other component.

I've thought about doing exactly this, in fact.  I haven't actually looked at the code in detail yet, but based on the documentation of the configuration files, I'm thinking to extend the concept of configurations to cover non-D build rules.

Essentially, the current concept of a "package" is more-or-less equivalent to a subgraph in a generic build graph where the inputs are a particular collection of D source files, and the output is a D executable or library.  Thanks to dub's built-in backward compatibility measure of ignoring unknown directives, one could retroactively say that current packages have implicit settings whose default values are those that designate the package as a D build, with the current semantics. When these (new, but retroactively interpreted as implicit) settings are modified, they change the semantics into non-D builds.  Thus, the concept of a package can be extended to non-D builds in a backward compatible way that does not require modifying existing dub packages.

I'm not sure how amenable the current dub code is to this modification, but worse comes to worst, one can always rewrite this part of the code from ground up, following the current specifications for the existing configuration parameters, and adding new parameters with the new semantics. Possibly reuse dub's test suite to ensure backwards compatibility.  Or perhaps even the nuclear option of rewriting the code from scratch while maintaining the ability to parse existing dub.json/dub.sdl files so that existing packages can transition with zero change.


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.