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

[Mike Parker]

On Monday, 25 April 2022 at 20:12:19 UTC, deadalnix wrote:

> The least power for the job definitively implies not inserting 
> a build system in the package manager.

I'm posting in reply to deadalnix, but my comments are not 
directed at him specifically.

dub exists because it filled a huge, gaping hole in the D 
ecosystem.

Go back far enough and you'll find "build", later renamed "bud", 
by Derek Parnell. This was the first D build tool the community 
rallied around. Several D users adopted it.

https://www.digitalmars.com/d/archives/digitalmars/D/40914.html

Gregor Richards wasn't happy with bud, so he created "Rebuild" as 
an alternative build tool, but added a package manager on top of 
it called "DSSS" (D Shared Software System). Rebuild actually 
parsed source files looking for custom pragmas, and IIRC DSSS 
could install packages from multiple locations (svn, git, etc). 
Several D libraries users adopted it.

https://forum.dlang.org/thread/f06hsi$ng1$2@digitalmars.com

So let me tell you, this sounds but it was also a serious PITA as 
a library maintainer. You had the bud crowd demanding support for 
bud, the dsss crowd demanding support for dsss, and the crowd who 
refused to use either because make was good enough. At one point 
I had three platform-specific make files, a `dsss.conf`, and a 
`forbud.txt` (I eventually replaced some of that with a 
`buildme.d file`).

There was no standard way of building D projects, and it sucked. 
Then Derek and Gregor disappeared, and suddenly these build 
systems everyone is using are no longer supported. No one takes 
them over, so we're in the Dark Ages again. Then dub comes along 
and saves the day.

It caught on quickly. Then people start thinking: "What happens 
if Sönke disappears? This should be an official D thing." So dub 
gets added to the installation. And here we are.

Without dub, we would not have the ecosystem that we do have. 
Personally, I love it. It makes using dependencies a snap. I'm 
happy with the default source tree expectations, and I don't mind 
compiling C libraries separately when I need them.

But I understand that no everyone is going to be happy with it (I 
don't understand the level of hatred some people direct at it, 
but I just chalk it up as "they aren't happy with it" and move 
on).

The question is, what exactly is dub missing and how can it be 
improved? Which perceived shortcomings are reasonable to address 
and which are not? And assuming we can answer those questions, 
who is going to address them?

We tried to secure funding a while back for someone to oversee 
development more actively since Sönke is too busy to spend the 
time on it that he used to, but that didn't happen. And no one on 
the core team has the time needed to steer the project. So until 
one of those things changes, the only way it's going to happen is 
if one or more people step up and make it happen.

So I propose someone, anyone, who has an interest in seeing dub 
evolve raise their hand and take on the task of gathering 
requirements. Not dive in and start refactoring code, not sit 
down and write a new build tool, but to gather the gripes and 
complaints from bitch sessions here and on Discord and distill 
them into lists of needs, wants, and nice-to-haves. (I'd do it 
myself, but I just don't have the time.)

Then that list can be a starting point for a plan to move 
forward. I'm sure I can put together a team of interested parties 
willing to donate a little of their time to provide input on 
formulating that plan. Then we can look at how to actually get 
the work done, e.g., putting out a task list that contributors 
can spend time on, picking out more complicated tasks for 
contract work funded from our ecosystem fund, etc.

So please, someone take all this energy directed at telling us 
all how terrible dub is and take the first step toward 
redirecting at turning dub into something more of us are willing 
to use.