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

[H. S. Teoh]

On Tue, Apr 26, 2022 at 07:06:50PM +0000, Alexandru Ermicioi via Digitalmars-d wrote:
> On Tuesday, 26 April 2022 at 18:14:20 UTC, H. S. Teoh wrote:
> > 
> > Right, which brings me back to square one. Dub already knows how to
> > cache stuff, but I can't leverage any of it because it was
> > arbitrarily decided that dub would only work with D source files,
> > and therefore it only caches D artifacts.  If I want to build HTML
> > files from templates, for example, I couldn't leverage dub's caching
> > ability; I have to roll my own and reinvent the square wheel.  If I
> > want to build PNG files from data files, I'd also have to roll my
> > own cache.  Eventually, I'd want to avoid reinventing my own cache
> > for every artifact I want to build, so I'd look for a system that
> > offers me that capability.  Such a system would obviously also be
> > able to build D programs and cache them as artifacts, since building
> > D programs would be a specific case of the more general task of
> > building a target from sources and caching it.  Which in turn means
> > that dub has just become redundant: I might as well just use that
> > other system for *all* my build needs, including building D
> > programs, and it would let me do everything I need without needing
> > to work with two different, overlapping systems (dub + other build
> > system).
> > 
> > That's my current line of reasoning, and why I haven't seriously
> > invested in dub.
> 
> So, perhaps dub itself should be used as part of your more general
> build system to build D code only?

But why would I even need dub when the more general build system also
handles building D code just fine?  Unless the boss dictates that I
absolutely have to use dub *somewhere*, just for the sake of using dub,
then it's just a redundant gear doing what other gears are already
doing. Might as well economize and take it out completely.


> Perhaps, there should be some integrations of of dub with other
> popular tools, so such use would be less painful.

If we want more widespread adoption of dub, I would say this is
absolutely essential.


> That is ofc, in case you want your code available for others to use
> where you work, or by public.
[...]

The problem right now is, even if I want my code to be available to
others, dub may not be able to do it.

E.g., if part of my D source files is autogenerated from data files
using an auxiliary utility (also written in D), then dub wouldn't even
know how to build such a thing. I can call dub from my build system and
it'd work, but anyone else who uses dub to download my package would not
be able to use it because dub doesn't know how to build it, and that
person would not know to run another build system to make it work.

To make it work, I'd have to jump through lots of hoops and write a
whole bunch of extra scripts to be called from dub's "preBuildCommands",
that essentially duplicates what my other build system is already doing.
It's a lot of redundant bending over backwards just to work around dub's
limitations.  Unless my boss is holding a gun to my head and demanding
that I make it work, the chances of me putting in this effort is nil.

Dub needs to expand its horizons and break out of its own walled garden.


T

-- 
Time flies like an arrow. Fruit flies like a banana.