Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa)]

On 02/11/2018 09:01 PM, Jonathan M Davis wrote:
> On Sunday, February 11, 2018 20:30:19 Nick Sabalausky  via Digitalmars-d
> wrote:
>> The langauge-based package managers just simply need to keep
>> "buildsystem" OUT of the package manager's scope. That's all. THAT is
>> why system-level packages can be built with whatever tool: because the
>> one thing the system package managers actually do get right is NOT
>> rolling their own mandatory buildsystem.
> 
> I'm not sure that it's entirely a bad thing that dub includes a build system
> in it, since it's the ease of use of its build system that is part of why
> it's so worth using. It's just that its simplicity is also part of why it
> doesn't work well once you get out of the basic situation of "here's a group
> of D files that need to be compiled together as a library or application."

You're right, of course. I guess I wasn't clear about this, and frankly 
I even lost sight of it, but if it HAD been easy and clear to just say 
"hey, dub, I'm bringing along my own buildsystem and opting out of 
yours, ok? thanks dude" and that was that, no muss, no fuss, no 
"tricking" dub into doing what I need, I would've been fine with that.

The problem is that, in my experience, dub's assumptions about it doing 
your build for you tend to be so deeply ingrained into the way it and 
its configuration format all work, that I just don't see attempts to 
separate them out as likely work out all that well. If even at all.

Heck, at this point I feel like most of my attempts to get dub to do 
anything I have in mind have wound up being less "what is the directive 
to do that?" and more "How to I nudge, persuade, or outright trick dub 
into doing what I need?" Even if I just have a compiler switch I want to 
use, or not use, I can't *just use it*. Best case scenario, dub will 
brand my library with a big ugly warning when anyone uses it. More 
likely, I have to go translate it into dub-speak (if I'm LUCKY), or, all 
too frequently, I find myself flailing around, trying to find just the 
right combination of settings to *coax* dub's behavior.

This is a completely *typical* dub experience for me, and frankly, one 
of the more *pleasant* ones:
https://github.com/atilaneves/unit-threaded/issues/106

Did you know dub behaves *differently* if your test configuration is 
named "unittest" verses when it has a different name? I didn't. 
Principle of most surprise, I guess.

THIS is me using dub. Flawless illustration:
https://www.youtube.com/watch?v=QvcFRgJwE2k&t=0m12s

> The problem with that approach though (and part of why I think dub doesn't
> do that) is that if dub really is set up with the idea that you use whatever
> build system you want, then you have the issue of whether the system doing
> the build has all of the necessary software to do the build.  Dub doesn't
> completely avoid that as-is, since you can depend on certain libraries being
> on the system,
 > [...]But if dub itself were designed with the idea that you could
 > use cmake, scons, make, or whatever build system anyone felt like putting
 > together, then there's a fairly high chance when you go to pull in a 
package
 > from dub that it's going to require stuff to build that you don't have on
 > your system, and since you frequently end up pulling in packages 
recursively

That's why the way it *should* work is: If your build has a dependency 
(another .d lib, a C lib, cmake, rake, scons, whatever), you make a dub 
package for it if there isn't already one. Problem solved.

But once again, dub's assumption that *everything* is a set of *.d files 
for it to complile gets in the way here too.

> So, dub's solution of targeting a single build system side steps that issue
> to a great extent - not entirely, but enough that it doesn't tend to be a
> problem. And on some level, that's a good thing,

No, all it does it create problems and prevent workarouds, as described 
above. If a package needs, ex, scons, to build, it should be simple to 
create a dummy dub package for scons that (best case) offers to install 
scons for you, maybe even a local non-system-wide installation, or at 
the very least, tells the user, "hey, scons not detected, it's a 
dependncy of this package, so you need to install it."

After all, managing dependencies are what package managers are all 
about, and dub isn't handling it very well when it comes to tool 
dependencies (as opposed to "a library of .d files to be linked in" 
dependencies, which is really all it's designed for).

> 
> So, I don't know what the right solution is.

The right solution is to give up on dub, as it's too far down the wrong 
design road, and have a package manager that's designed from the ground 
up to be a package manager (not a simplified buildsystem that happens to 
also include dependency-handling features). As a package manager, 
*anything* the package needs, a D library, a C library, an external 
tool, even a compiler version and the package manager itself...is just 
another dependency for the package manager to handle.

I should point out, strong as I may feel about all this, I don't mean to 
be too much of a dick about dub. I'm well aware how much effort went 
into dub, and I *do* respect that. Frankly, I've always been absolutely 
*stunned* by just how much Sonke accomplishes. Beyond me how he manages 
to do all that: I know I certainly couldn't. It seems superhuman! And I 
am grateful there's been at least SOMETHING for D package management.

It's just, from a technical perspective looking toward the 
near/mid-future, I just have a hard time seeing dub getting to where we 
really need a D package manager to be, and I admit I've gotten to the 
point of real frustration.