Git, the D package manager

[Sönke Ludwig via Digitalmars-d]

Am 02.02.2015 um 10:44 schrieb Andrej Mitrovic:
> 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/).

There is a request to make this configurable and it's a rather trivial 
addition. I just don't have the time to implement all feature requests 
myself, which is basically why it is not implemented, yet.

However, you are free to instead put the packages wherever you want 
instead and use "dub add-path" (or "add-local") to register it with DUB. 
You will just have to manually fetch the sources in this case.

You are also free to use git submodules and use a path based dependency 
to force using that particular instance of a package. The only caveat is 
that this will not work for public packages because there is no straight 
forward way to handle submodules properly when GitHub et al. are involved.

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

If this is true for a certain error message, please submit a ticket (or 
better yet, a quick pull request). Stack traces are supposed to be 
emitted only when the -v or --vverbose command line switches are present.

> - 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 don't get this. You'd usually use something like `"somedep": 
"~>1.0.0"` in your dub.json. Whenever you then run "dub upgrade", it 
will update to the latest matching version.

Regarding the update frequency of the package registry, as the package 
maintainer you can often speed this up considerably by pressing the 
manual update button on the package management page. It would be better 
to use GitHub's hooks functionality to get instant updates, but that 
requires quite some more work, as well as registering each repository 
with the registry (using OAuth).

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

I didn't notice that thread, but did you try the most recent version? 
There are sub module related fixes in both 0.9.22 and on GIT master that 
could affect this.

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

We need more regression tests in the test suite, that's true. Going by 
the relative shortage of development resources, it would be helpful to 
get some feedback on such regressions, so that they get some extra 
priority. Right now I have barely enough time to fix issues or add 
important features, so a strict regression suite policy as for DMD 
unfortunately is just not realistic ATM.

>
> 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/