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
