Jump to page: 1 2
Thread overview
Two major problems with dub
Aug 01, 2021
Alain De Vos
Aug 01, 2021
Alain De Vos
Aug 01, 2021
evilrat
Aug 01, 2021
Paul Backus
Aug 01, 2021
Alain De Vos
Aug 01, 2021
Adam D Ruppe
Aug 01, 2021
Alain De Vos
Aug 01, 2021
evilrat
Aug 04, 2021
Denis Feklushkin
Aug 04, 2021
evilrat
Aug 04, 2021
Adam D Ruppe
Aug 01, 2021
Paul Backus
Aug 01, 2021
rikki cattermole
Aug 04, 2021
Denis Feklushkin
Aug 04, 2021
Guillaume Piolat
August 01, 2021

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.
August 01, 2021

Is there a security review for dub packages ?

August 01, 2021

On Sunday, 1 August 2021 at 15:38:32 UTC, Alain De Vos wrote:

>
  1. 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)

August 01, 2021

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.

August 01, 2021

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.

August 01, 2021
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.
August 01, 2021

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.

August 01, 2021

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?

August 01, 2021

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.

August 02, 2021
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
« First   ‹ Prev
1 2