DUB - call to arms

[Nick Sabalausky (Abscissa)]

On 4/17/19 4:10 PM, JN wrote:
> On Wednesday, 17 April 2019 at 19:15:40 UTC, Nick Sabalausky (Abscissa) 
> wrote:
>> On 4/17/19 1:53 PM, H. S. Teoh wrote:
>>> At the end of
>>> the day, it just boils down to (1) you have a bunch of input files, (2)
>>> there's some command that transforms these input files into output
>>> files, and (3) these output files reside somewhere in the filesystem.
>>> As long as you're told where the output files in (3) are, you know
>>> enough to use this package.  What goes on inside (2) is irrelevant; said
>>> command can be arbitrarily complex -- it can be an entire build system,
>>> for example, that consists of many subcommmands -- but a package manager
>>> doesn't need to (and shouldn't) care about such details.
>>
>> +1, exactly correct
> 
> In the ideal world, perhaps.

No, there's no "ideal world" about this. What HSTeoh describes above are 
just plain the cold, hard facts of the matter. No ifs, ands or buts.

The complications that we're accustomed to seeing and expecting are ones 
that come straight from DUB's failure to fully separate package 
management from building.

> I am just worried opening dub to other 
> build systems will just open a can of worms. Packages will use different 
> build systems, which will be a pain to set up. Right now, the advice is 
> "to get started with D, install official DMD distribution and set up 
> your project with dub". Afterwards, the advice may be "to get started 
> with D, install official DMD distribution, set up your project with dub, 
> and install git,svn,meson,scons,make,cmake so that you can build some 
> packages. Oh and set these environmental variables for these tools. Oh 
> and if you're on Windows you're screwed".

With what I have in mind (and HS Teoh appears to have the same thing in 
mind), then no, those scenarios are absolutely, definitely not a 
realistic result. They're just fear-based speculation at best.

In the long run, DUB may or may not remain the recommended buildsystem 
for newcomers, but that's all. And it least it won't actively PREVENT 
alternative buildsystems from coming along and proving superior enough 
to dethrone DUB.

> While dub may seem limiting to some, it offers standarization and 
> unification.

Well that's just the problem - It *doesn't* provide that, it completely 
fails to. It tries to standardize and unify through basically the same 
strong-arm "submit or die" approach as Nobunaga or Napoleon, but as I 
predicted it would from the start, it just would up fracturing the 
ecosystem instead[1]. And a fractured ecosystem is by definition NEITHER 
standardized NOR unified.

[1] The no-so-well-known fact is, many projects are forced out of the 
DUB package ecosystem because of DUB buildsystem's limitations. Though 
that may not be easy to see, since such packages are forced 
under-the-radar because of their opting out of DUB as a buildsystem also 
forces them out of the visibility provided by code.dlang.org. And then 
the ones that do join the DUB side are too often forced into hardships 
that first of all, shouldn't even be necessary, and second of all, still 
fail to offer the tradeoff of unifying/standardizing the ecosystem anyway.

The *only* way to standardize and unify is to do so in a way that allows 
individual packages to work the way they need to.