www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Two major problems with dub

reply Alain De Vos <devosalain ymail.com> writes:
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.
Aug 01 2021
next sibling parent Alain De Vos <devosalain ymail.com> writes:
Is there a security review for dub packages ?
Aug 01 2021
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Sunday, 1 August 2021 at 15:38:32 UTC, Alain De Vos wrote:

 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.


Wait, you don't use isOdd package in your frontend? No way...

(also for that "bloat" part, this is where the linker comes in 
and strips it all, unless you are talking about accidentally 
added dependencies on "just in case" basis which is a sign of 
design issues)
Aug 01 2021
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 1 August 2021 at 15:38:32 UTC, 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.


It seems to me like these are not really problems with the dub 
package manager or the dub archive itself, but with the quality 
of individual packages.

There is a community-maintained list of high-quality D resources 
(including dub packages) available on github:

https://github.com/dlang-community/awesome-d

Ideally, something like this would be integrated into 
code.dlang.org itself, so that users could see at a glance which 
packages are considered high-quality by the D community.
Aug 01 2021
parent reply Alain De Vos <devosalain ymail.com> writes:
A simple and small wrapper around for instance the C-library 
libpq should be part of the language itself and should not pull 
in more than libpq itself.
Aug 01 2021
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 1 August 2021 at 17:18:39 UTC, Alain De Vos wrote:

 A simple and small wrapper around for instance the C-library 
 libpq should be part of the language itself and should not pull 
 in more than libpq itself.


i have one of those in two files: database.d for the interface 
and postgres.d for the impl found in here 
https://github.com/adamdruppe/arsd

are you suggesting some kind of mandatory review to be featured 
on dub? that might not be a bad idea actually.
Aug 01 2021
prev sibling next sibling parent reply Alain De Vos <devosalain ymail.com> writes:
A simple example, dub package dpq2 pulls in,
money,vide-d,stdx-allocator,derelict-pq,derelict-util
This all for a handfull of C-functions.
Aug 01 2021
parent reply evilrat <evilrat666 gmail.com> writes:
On Sunday, 1 August 2021 at 17:25:26 UTC, Alain De Vos wrote:

 A simple example, dub package dpq2 pulls in,
 money,vide-d,stdx-allocator,derelict-pq,derelict-util
 This all for a handfull of C-functions.


let's see

Money - fits pretty ok, cause your average SQL has decimal type 
for that purpose but there is no built-in one in D

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

stdx-allocator - memory management, and it is also possible to 
reduce GC pauses it is probably uses malloc'ed buffers

derelict-pg - C API wrapper for PostgreSQL

derelict-util - handles function pointers loading for that wrapper


That's it. Why do you think this is bloat? You know, D coders are 
very careful when it comes to using dependencies, it's not like 
in JS where shit got imported just because it exists, so I don't 
get your complains on that.
Aug 01 2021
parent reply Denis Feklushkin <denis.feklushin gmail.com> writes:
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
Aug 04 2021
parent reply evilrat <evilrat666 gmail.com> writes:
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.
Aug 04 2021
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
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.
Aug 04 2021
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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](https://github.com/denizzzka/dpq2/blob/c1f1c7c26f7e6cac7a34778dc580c92d8dec013b/dub.json#L12).

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

-Steve
Aug 04 2021
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 1 August 2021 at 17:18:39 UTC, Alain De Vos wrote:

 A simple and small wrapper around for instance the C-library 
 libpq should be part of the language itself and should not pull 
 in more than libpq itself.


I don't disagree. The question is, who will volunteer to create 
and maintain this wrapper?
Aug 01 2021
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 02/08/2021 5:18 AM, Alain De Vos wrote:

 A simple and small wrapper around for instance the C-library libpq 
 should be part of the language itself and should not pull in more than 
 libpq itself.


Just so that we are all using the same terminology.

A binding defines the functions and types as per the external libraries 
headers.
It may be dynamically loaded and require a loader also, there is no 
bloat for this.

A wrapper uses a binding but makes it more D friendly or even  safe. I 
think based upon your description that you are looking for a binding not 
a wrapper.

The only binding I could find was derelictpq which hasn't been updated 
to bindbc (not that it should matter too much). 
https://github.com/DerelictOrg/DerelictPQ
Aug 01 2021
prev sibling parent Denis Feklushkin <denis.feklushin gmail.com> writes:
On Sunday, 1 August 2021 at 17:18:39 UTC, Alain De Vos wrote:

 A simple and small wrapper around for instance the C-library


Really, dpq2 is that wrapper
Aug 04 2021
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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/datepar
er/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
Aug 02 2021
parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 3 August 2021 at 00:54:56 UTC, Steven Schveighoffer 
wrote:

 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


I don't think optional dependencies are truly the answer.
There are ways to fix this otherwise is to break dependency 
chains when only a small part is used.
In this case:
- use a GC slice
- use malloc
- use std.experimental.allocator

My pet peeve is the isfreedesktop package. 
https://github.com/FreeSlave/isfreedesktop/blob/master/source/isfreedesktop.d
package :)
Yes it is annoying, but with a bit of copy-paste you can break 
dependencies chain and avoid the npm situation where "640 
packages were installed"
Aug 04 2021