Make dub part of the standard dmd distribution

[Sönke Ludwig via Digitalmars-d]

Am 04.06.2015 um 15:07 schrieb Steven Schveighoffer:
> On 6/4/15 4:58 AM, Sönke Ludwig wrote:
>>
>> As of recently, you can also directly specify dependencies to the "dub
>> init" command, for example "dub init myproject tango derelict-gl".
>
> That's nice. But it still isn't self-explanatory. Nor additive.

A command to add/remove dependencies might be useful. But the question 
is where to stop. Does it make sense to have a command to edit the 
description? Or add compiler flags? Or manage configurations or sub 
packages? It also gets a little hairy w.r.t. keeping possible user 
formatting in the package description file, especially once support for 
comments gets added.

>
>> There
>> was also the suggestion to make dub init (without arguments)
>> interactive, which would make this a really easy matter.
>
> This would be better, but I still think a way to add dependencies should
> be supported on the command line. Something like dub depend someproject.
> You don't always know what a project will need at the beginning.
>
> Of course, you could just say "well, edit the json file!". You really
> need a format that supports comments...

Agreed, that is really needed. It's almost on top of the TODO list.

>
> In any case, this doesn't negate the concerns others have raised.
>
> I don't mean to bash dub, it's better than nothing. But I haven't used
> it for any real project yet. And when I did use it, it was not a
> straightforward experience.
>

The important part is to not stop with voicing criticism, but to 
actively help to improve the situation. Opening tickets or "voting" on 
existing ones, or even making an enhancement proposal or an actual PR 
would be the most constructive.

It's a little sad how some people seem to perceive DUB as being static 
and unable to evolve. That is not the case. It has started out with a 
small core functionality to get something that benefits a lot of people 
right away. But everything has been done in a way that allows to extend 
or generalize things later.

Not everyone will agree with its philosophy to provide high level 
declarative abstractions instead of a low level system that can be used 
to create abstractions within the build language, but I'm very positive 
that this approach is much more useful for the vast majority of users 
(and especially for newcomers). Retrofitting existing build approaches 
can of course sometimes come with friction, but even that should be 
solvable one way or another in most cases.

In any case, probably all of the mentioned criticism so far seems to be 
based on nothing more than missing functionality or bugs and nothing 
that would go against the existing design. An exception is support for 
other high level tasks, such as "deployment" targets or similar. This 
has never been the scope and I don't think we should go that way.

On a related note, it's also a pity that Reggae mixes incremental build 
improvements (from which DUB itself could greatly profit, too - just as 
a Ninja generator for DUB would be a nice feature) with a separate, 
layered build description. I mean there is of course no reason to not 
have alternative approaches for build descriptions available in general, 
but when mixed with a public package repository, it just leads to 
fragmentation.

Sorry for the slightly OT reply, most of this isn't targeted at you, I 
just went through the newsgroup posts for the first time after a while 
and needed to get this out.