I like dlang but i don't like dub

[Ali Çehreli]

tldr; I am talking on a soap box with a big question mind hovering over 
on my head: Why can't I accept pulling in dependencies automatically?

On 3/18/22 07:48, H. S. Teoh wrote:

 > As a package manager, dub is OK, it does its job.

As a long-time part of the D community, I am ashamed to admit that I 
don't use dub. I am ashamed because there is no particular reason, or my 
reasons may not be rational.

 > As a build system

I have seen and used a number of build systems that were started after 
make's shortcomings and they ended up with their own shortcomings. Some 
of them were actually program code that teams would write to build their 
system. As in steps "compile these, then do these". What? My mind must 
have been tainted by the beauty of make that writing build steps in a 
build tool strikes me as unbelievable... But it happened. I don't 
remember its name but it was in Python. You would modify Python code to 
build your programs. (?)

I am well aware of make's many shortcomings but love it's declarative 
style where things happen automatically. That's one smart program there. 
A colleague loves Bazel and is playing with it. Fingers crossed...

 > I much rather prefer Adam's arsd libs[1], where you can literally just
 > copy the module into your own workspace (they are almost all standalone
 > single-file modules

That sounds great but aren't there common needs of those modules to 
share code from common modules?

It is ironic that packages being as small as possible reduces the chance 
of dependencies of those modules and at the same time it increases the 
total number of dependencies.

 > The dependency graph of a project
 > should not be more than 2 levels deep (preferably just 1).

I am fortunate that my programs are commond line tools and libraries 
that so far depended only on system libraries. The only outside 
dependency is cmake-d to plug into our build system. (I don't understand 
or agree with all of cmake-d but things are in an acceptable balance at 
the moment.) The only system tool I lately started using is ssh. (It's a 
topic for another time but my program copies itself to the remote host 
over ssh to work as a pair of client and server.)

 > You shouldn't have to download half the world

The first time I learned about pulling in dependencies terrified me. 
(This is the part I realize I am very different from most other 
programmers.) I am still terrified that my dependency system will pull 
in a tree of code that I have no idea doing. Has it been modified to be 
malicious overnight? I thought it was possible. The following story is 
an example of what I was exactly terrified about:

 
https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Despite such risks many projects just pull in code. (?) What am I missing?

I heard about a team at a very high-profile company actually reviewing 
such dependencies before accepting them to the code base. But reviewing 
them only at acceptance time! Once the dependency is accepted, the 
projects would automatically pull in all unreviewed changes and run 
potentially malicious code on your computer. I am still trying to 
understand where I went wrong. I simply cannot understand this. (I want 
to believe they changed their policy and they don't pull in 
automatically anymore.)

When I (had to) used Go for a year about 4 years ago, it was the same: 
The project failed to build one morning because tere was an API change 
on one of the dependencies. O... K... They fixed it in a couple of hours 
but still... Yes, the project should probably have depended on a 
particular version but then weren't we interested in bug fixes or added 
functionality? Why should we have decided to hold on to version 1.2.3 
instead of 1.3.4? Should teams follow their many dependencies before 
updating? Maybe that's the part I am missing...

Thanks for listening... Boo hoo... Why am I like this? :)

Ali