The DUB package manager

[Sönke Ludwig]

Am 17.02.2013 10:24, schrieb Russel Winder:
> On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote:
> 
>> I agree about the non-optimal syntax, but it comes down to nicer syntax
>> (where JSON at least is not _too_ bad) vs. standard format (familiarity,
>> data exchange, proven design and implementation). And while data
>> exchange could worked around with export/import functions, considering
>> that these files are usually just 4 to 20 lines long, I personally would
>> put less weight on the syntax issue than on the others.
>>
>> BTW, I think YAML as a superset of JSON is also a good contender with
>> nice syntax features, but also much more complex.
> 
> Peter's point is more important than the above response indicates.
> 
> Using JSON (YAML, whatever) is a recipe for failure. The syntax is data
> exchange facing, whereas writing and maintaining a build script (even if
> it is only 4 lines long), is a human activity. Do not underestimate the
> reaction "why do I have to write this data exchange format?" The rapid
> demise of XML, Ant, Maven, etc. is testament to people awakening to the
> fact that they were forced to use manually a language designed for
> another purpose.

I don't agree with this, as already said in my response to Peter. We are
talking about rather small syntactic differences here (i.e. ',' vs ';'
and omitting quotes) and XML adds a lot more overhead than the quotes
around key names.

Ant and the like also have the awkward approach of not only using a
verbose format such as XML, but they also try to express procedural
build scripts in that language, which is insane. But my idea for dub is
to completely avoid the need for procedural build steps apart from
invoking an external tool (which should be needed only for a minority of
D projects).

> 
> Where Gradle, and before it Gant, Buildr, etc., got it right was to use
> an internal DSL mentality to ask what is a written form that has
> affordance for the user that we can interpret in some way to deliver for
> computation the data needed. Groovy provides the infrastructure for
> Gradle, but people write Gradle scripts not Groovy. The build/packaging
> system does the hard work, not the user.
> 
> The lesson from SBT is that by judicious cleverness, a trivially simple
> internal DSL can be derived that does all the work using Scala. The only
> downside to SBT scripts is the extra newline needed everywhere. Surely D
> is better than Scala for this?

If by internal DSL, you mean compiled as D source code directly or
indirectly, please also consider the server side issues (i.e. danger of
DoS and hijacking the system).

> 
> So if D is to contribute to build and package management, it should be
> looking to replace Make, CMake, SCons, Waf, Gradle. It should be able to
> build D systems yes, and manage D packages, but also look to build C, C
> ++, Fortran, and interlink all of them. Clearly starting small is good:
> a successful large system always evolves from a successful small system;
> designed large systems always fail. (cf. Gall, Systemantics, 1975)

I think building foreign languages are better left to specialized tools.
It should be possible to invoke those automatically, but adding their
functionality directly to a D build system would blow up the complexity
dramatically for an uncertain return of value (what would be the problem
invoking make to build a C dependency?).

My question if we can get by without procedural build scripts is still
open. If we could, it would give great benefits in simplicity of the
system and its usage. This may require a change in conventions for some
projects, but I think that can be worth it.

Maybe it would be good to have some concrete examples of complex build
scenarios to better judge what is possible and what may be problematic.