On Tuesday, 3 February 2015 at 02:19:56 UTC, Martin Nowak wrote:
> There seems to be a general scepticism against dub and I wonder what the reasons are.

Personally I love it and have had no problems with it, so yeah...

On Monday, 2 February 2015 at 22:42:35 UTC, ponce wrote:
> - choosing if they want breaking changes.

Currently I have a super-simple way to deal with breaking changes:

I prefix the commit message with "[BREAKING] ".

Not perfect, but it makes tracking them down much easier in the history.

On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote:
> Change my view.

Thanks for the great discussion, everyone.

I agree, Git does not scale for version/dependency management. Diamond dependencies are the killer argument. I had not run into this because I pile everything reusable in a single repository.

I might revisit Dub again once some of the fixable issues mentioned here are fixed.

Lot's of weird attitude in this thread BTW, instead of complaining about every single flaw we could really make use of a few helping hands.
I'm often literally baffled that people don't even try to fix obviously trivial bugs.
https://github.com/D-Programming-Language/dub/pull/354

On Tuesday, 3 February 2015 at 02:39:56 UTC, Vladimir Panteleev wrote:
> I might revisit Dub again once some of the fixable issues mentioned here are fixed.

Another very important argument is consistency in using packages.
I recently tried digger which is a really great tool, but it took me about 5 min to get it running.

- make temp folder
- copy URL from github & clone & cd digger
- search build instructions README/INSTALL/wiki/main.d
- rdmd --build-only digger => linker error
- Wondering, if I really have time for this?
- ah, need to clone all submodules
- rdmd digger --help

With dub you do this instead.

dub fetch digger
dub run digger -- --help

That works in whatever folder you are, builds a stable version of the tool and even links against already installed and build dependencies.

On Monday, 2 February 2015 at 09:44:18 UTC, Andrej Mitrovic wrote:
> - 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/).

It has the benefit of not reusing code and libraries across multiple projects.

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

Definitely guilty of bad exception usage.

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

Never had a problem with add-local, but I didn't use it with sub packages yet.
In fact sub-packages are overused and fairly complex. Configurations can handle most of the tasks much simpler.

> - Shit breaks every N releases (where N is arbitrary).

It's still beta and a fast moving project, but we're stabilizing.

On Tuesday, 3 February 2015 at 03:20:49 UTC, Martin Nowak wrote:
> - rdmd --build-only digger => linker error
> - Wondering, if I really have time for this?

Hmm. Fixed ;)

https://github.com/CyberShadow/Digger/commit/b6d06be2346986a74937c918ed1d4ac121a9819f

I wasn't forgetting C++ integration, if I do this that'd be a main part of the build system.

Ugly doesn't do the CMake scripting language justice. CMake is like democracy; terrible, but better than everything else. I think I can do better but I need to figure out a bunch of details.

Atila


On Monday, 2 February 2015 at 20:05:38 UTC, Dragos Carp wrote:
> On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote:
>> This thread has just made me decide to write a D build system, in D and configured in D that builds on dub and its packages intead of reinventing the wheel. I might ask the community for inputs on requirements. Maybe this will be my DConf 2015 submission.
>
> Why not building on cmake? You have experience with it. trentforkert made very good progress with D support in cmake and has good chances to merge it upstream [1].
>
> If we look at the Vision/2015H1 goals, we see a couple of points, where cmake already has the necessary support:
>
> - C++ integration (hybrid projects)
> - alternative compilers
> - embedded systems
>
> This features would take a lot of effort/time to be implemented in a pure D solution, nevertheless any of these points is a niche in the D community.
>
> Apart from the ugly script language, cmake would be a pretty good fit.
>
>
> [1] - https://github.com/trentforkert/cmake

On Tue, 03 Feb 2015 02:19:55 +0000, Martin Nowak wrote:

> There seems to be a general scepticism against dub and I wonder what the reasons are.

'cause it really sux as a build tool.

On Tue, 03 Feb 2015 02:44:01 +0000, Martin Nowak wrote:

> I'm often literally baffled that people don't even try to fix obviously trivial bugs.

maybe that's 'cause they have their work to do, and fixing bugs in dub is not a part of that work?