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.
