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

[H. S. Teoh]

On Mon, Apr 25, 2022 at 04:05:10PM +0000, deadalnix via Digitalmars-d wrote:
> On Monday, 25 April 2022 at 11:18:57 UTC, bauss wrote:
> > This discussion would never have happened if the project was just
> > created with dub in mind from the beginning, like if it was built
> > using dub since the beginning and not with make, or at the very
> > least both.
> 
> Good, what's you plan to get every project restarted from scratch
> using dub?

One ideological struggle I have with dub is that it imposes its
worldview upon your project, instead of fitting itself into what already
exists, like many other systems do.

I've worked with integrating software with OS package managers, for
example, and they often involve simply adding some files, or maybe a
subdirectory or two, to your existing source tree, and the packaging
tools pick it up from there.  None of them involve mandatory,
dictated-from-above reorganization of the source tree structure to fit
its ideals (such a thing would have quickly become too onerous to use --
people would just give up trying to cater to the system, and the
repository would just stagnate from a dearth of people who are willing
to go far enough to satisfy its whims).

Or take the old workhorse Make, which everybody (including myself)
hates. It does not require you to reorganize your source tree to fits
its worldview; all it needs is to add a Makefile with the right
contents, and it Just Works(tm).  The same can be said for a multitude
of other Make-replacement build systems.

But not so for dub. It demands that you conform to its conventions,
otherwise it flat out doesn't work (or refuses to).  It doesn't play
well with external tools: it's theoretically *possible* to invoke other
tools if you ask really nicely, but it's glued on as an afterthought,
the core design obviously does not acknowledge such usage.  It does not
support customization -- you either do things its way, or the highway.

And most importantly of all -- it does not integrate nicely with
existing codebases that are already working with a different system.
This is especially bad for a small ecosystem that's trying to grow. When
the hurdle to adoption involves such efforts as restructuring your
entire danged source tree to fit dub's completely (and needlessly)
arbitrary requirements, guess how many eager projects are rushing to
contribute.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen