Git, the D package manager

[Sönke Ludwig via Digitalmars-d]

It looks like the core issue is that we simply have different goals in 
mind. When we were deciding on how the build description works back 
then, we basically had these:

  - The build description can be reasoned about in a generic way (not 
generally possible with an imperative scripting language)
  - It avoids security issues when doing so (DoS, attack surface for 
more sophisticated attacks), so that it can be done on a server with 
decent confidence and without expensive safeguards
  - It avoids dependencies on the host environment, so that reasoning 
about the build description can be done independently of the target 
platform/environment
  - Should work seamlessly for 99% of the projects, but allows to invoke 
external tools to handle the rest
  - Avoids any form of redundant information as far as possible (such as 
compiler or OS specific compiler flags)
  - Can be mapped to the typical IDE project file types, as well as to 
other kinds of build descriptions

The first goals are only achievable with either a declarative approach, 
or with a very limited imperative approach (which in the end is no more 
powerful than the declarative one). I also think that we can easily 
achieve the 99%/1% goal (if that has been reached already is difficult 
to tell, but with C-class language support it will most definitely be), 
and if we do, it's hard to justify why this approach with limited 
expressibility should be regarded as a failure.

I'm not sure why some people insist that it must be possible to achieve 
everything with one tool. Of course that is a noble goal and definitely 
can have its beauty, but, assuming that the 99%/1% rule holds, it may 
not be one that has much importance in practice (other than producing 
controversy). On the other hand, being able to reason about the build 
description without actually executing a build script on each of the 
interesting platforms/environments can be a big win and we'd otherwise 
lose some possibly important automation opportunities (mostly when 
talking about a public web service scale).

For me, the current solution seems to be a good trade off, ignoring the 
missing support for other languages for a moment. It has successfully 
laid the basis for a constantly growing ecosystem of pure D packages and 
now it's time to carefully support the more advanced use cases.

In this process, we can of course always go through the initial goals 
and revise them where appropriate, or evaluate any other possible 
approaches that can fulfill those goals. But we have to be very careful 
to not make the mistake and disrupt the existing ecosystem. Backwards 
compatibility is a must, and ideally any possible new approach should 
fit well with the existing system (it doesn't have to fit well with the 
JSON format, though, it just has to fit somehow).

One possible alternative to a full procedural build description could be 
the introduction of a plugin system, where each plugin is written in D 
and can be invoked from within the package description. I personally 
would like to let the selection of an approach be guided by actual use 
cases instead of just focusing on the maximum expressibility.