Git, the D package manager

[Andrej Mitrovic via Digitalmars-d]

On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev 
wrote:
> snip

Also:

- Dub installs everything in ~/ (home, which on Windows is an 
awful location anywho). It's a pain in the ass for browsing 
dependencies in your editor. If it's just a submodule you can 
easily view it in the source tree (e.g. just open ./submodules/).

Having it as a submodule also helps if you want to quickly try to 
edit a dependency in order to see if it fixes an issue. And if 
the fix is right you can even make a commit inside the submodule 
and push it to your fork of the dependency.

With all the aliases or zsh-tricks this can be as easy as a few 
key presses.

- By default dub emits internal stack traces. This is an insane 
amount of visual noise that I don't want to read.

- If I want to try a new version of a dependency, I have to 
change the damn .json package file instead of doing a simple 'git 
checkout ...'. What's worse, I have to wait 15-20 minutes for the 
latest tagged version of a dependency to finally show up on 
code.dlang.org.

I could use add-local, but it's broken[1].

- Shit breaks every N releases (where N is arbitrary). As if it's 
not enough that code tends to break between compiler releases, so 
do packages between DUB releases. Something that used to build 
half a year ago no longer does.

I don't recall when was the last time an RDMD or Make update has 
ever broken my projects.

- I'm not a fan of poorly tested software, and DUB falls into 
that category.

I've complained before about Git submodules being a bit broken on 
Windows, maybe this was fixed in the meantime. It works solidly 
on Linux, and I'm making the decision to transfer all my projects 
that use dependencies to using submodules instead.

The bottom line is, time spent on dealing with package management 
bugs is completely wasted developer time.

[1]: 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/5280/