Re: Two major problems with dub
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
Re: Two major problems with dub
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.
Re: Two major problems with dub
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"
Re: Two major problems with dub
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.
Re: Two major problems with dub
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
Re: Two major problems with dub
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
Re: Two major problems with dub
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
Re: Two major problems with dub
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
Re: Two major problems with dub
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.
Re: Two major problems with dub
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?
Re: Two major problems with dub
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.
Re: Two major problems with dub
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.
Re: Two major problems with dub
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.
Re: Two major problems with dub
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.
Re: Two major problems with dub
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)
Re: Two major problems with dub
Is there a security review for dub packages ?
