Two major problems with dub (page 2)

August 02, 2021

Re: Two major problems with dub

Posted by Steven Schveighoffer
in reply to Alain De Vos

Permalink

Steven Schveighoffer

Posted in reply to Alain De Vos

Permalink

On 8/1/21 11:38 AM, Alain De Vos wrote:

Dub has two big problems.

Unmaintained dub stuff.
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 project as a library. I found it was pulling in emsi-container, so it could have an array container (one line of code) 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

On Wednesday, 4 August 2021 at 08:18:34 UTC, evilrat wrote: > Than again like I said it is library author mistake, if only JSON is ever used then it should depend on vibe-d:data specifically and not the whole vibe-d thing. It is also a problem with dub though since D, the language, supports this just fine. If you use dmd -i, it only includes the specific modules you actually used. This can even get down to fine-grained functions if you code carefully, like if you use my dom.d you just need dom.d for most things. But call Document.fromUrl and now dmd -i pulls in my http2.d. Or Document.parseGarbage pulls in characterencodings.d. It does all that transparently based on your actual function calls thanks to those things being templates with local imports. But dub can't express that at all; it is incapable of using D's full modular strengths. This could be fixed.

On 8/4/21 4:18 AM, evilrat wrote:

On Wednesday, 4 August 2021 at 07:21:56 UTC, Denis Feklushkin wrote:

On Sunday, 1 August 2021 at 17:37:01 UTC, evilrat wrote:

vibe-d - probably because it handles DB connection and/or keep things async way, sure you probably can do it with Phobos but it will be much more PITA and less performant

It is because Postgres provides JSON types

Than again like I said it is library author mistake, if only JSON is ever used then it should depend on vibe-d:data specifically and not the whole vibe-d thing.

He is the library author. And that's exactly what he does.

Note that when you depend on a subpackage, it downloads the entire repository (it has to), but will only build the subpackage.

-Steve

Forums