The DUB package manager

[Sönke Ludwig]

Am 23.02.2013 10:20, schrieb SomeDude:
> On Sunday, 17 February 2013 at 08:02:41 UTC, Sönke Ludwig wrote:
>> To me the most interesting open question is this: Do we actually gain
>> from programmatic support for the build description, or does it suffice
>> to have a good purely descriptive system? If the former should be true
>> for more than 1% of the cases, that would definitely be a good argument
>> against pure data.
> 
> Well, in the Java world, there is ant. It does the trick, but it's quite
> ugly.

And it also does the really strange thing to actually build up a
procedural build description in a declarative (+ugly) language. That's
definitely not what I have in mind - what I want is really a pure
/description/ of the system, from which the build steps (or anything
else) can be inferred.

This has the big advantage that you can decouple the two concepts and do
generic things with all packages, even if the package maintainer didn't
explicitly write supporting code (e.g. generate documentation, generate
a project file, generate an installer, build as a DLL etc.).

The question is if we need procedural statements to create that package
description or not. So far I haven't really seen a compelling example
that we do. And staying with a declarative approach has the advantage
that the language is _not_ more powerful than the thing that it is
supposed to model, i.e. no information is lost.

An example where it is easy to mess up with a procedural language and
not have a real package description anymore is if the user uses the
scripting language to make decisions based on outside conditions (OS,
architecture, installed libraries, time of day, whatever). The result is
a description that is not really a description of the package anymore,
but of the package+environment, which makes it unpredictable and thus
impossible to safely make decisions about other environments (build
servers, cross compilation, platform independent list of dependencies
etc. pp.).