Two major problems with dub

[Steven Schveighoffer]

On 8/1/21 11:38 AM, Alain De Vos wrote:
> Dub has two big problems.
> 1. Unmaintained dub stuff.
> 2. Let's say you need bindings to postgresql library and you will see 
> dub pulling in numerous of libraries, which have nothing at all to do 
> with postgresql.
> More like a framework stuff. This creates unneeded complexity, 
> bloatware, dependency hell, maintainability, in my humble opinion. Dub 
> should do one thing and do it good.
> Feel free to elaborate.

My biggest pet peeve is when a library pulls in a unittest framework 
(which then might pull in all kinds of other things). I get it, and I 
get why it's needed as a non-optional dependency, but I have no 
intention on unittesting the library, I just want to use it. It's a 
shame to pull in everything that it needs because of that.

I recently added the 
[dateparser](https://code.dlang.org/packages/dateparser) project as a 
library. I found it was pulling in emsi-container, so it could have an 
array container ([one line of 
code](https://github.com/JackStouffer/date-parser/blob/55e6218427974051b5179c98e0828b1d2a17629e/source/dateparser/package.d#L807)) 
that enables use of stdx.allocator. Ironically, the default (and all I 
cared about) is using the GC allocator. I wish there was a way to make 
this dependency optional. If more dub projects used optional 
dependencies, that would be nice.

Given the way D works, and often template-heavy coding styles, I think 
it's going to be hard to do this correctly, without careful attention 
and lots of `version(has_xxx)` conditionals.

-Steve