Git, the D package manager

[Russel Winder via Digitalmars-d]

On Thu, 2015-02-05 at 18:01 +0100, Sönke Ludwig via Digitalmars-d wrote:
> 
[…]
>  I'm now just left wondering what it is that is "fundamentally 
> flawed". Everything mentioned so far is either
> bugs or missing functionality, or rather just mostly missing 
> convenience.

The core problem is the use of a JSON file to express the definition 
of the project. This sort of specification is fine for dependency but 
not sufficient for build.

Make is a fine external DSL for dependencies, but everything else 
relies on the action language, generally Bash. GNU Make adds macros 
and a whole slew of things to try and make things better, all of them 
adding more imperative aspects.

Autotools is a wonderful M4 edifice, but not a solution to the 
problems of project management Make despite many years of people 
actually succeeding in doing it.

CMake has a DSL for describing build, not so good on the project 
description side, but in the end the language is ugly, underpowered 
and reliant on Make.

SCons is not perfect, but it beats Make and CMake by creating an 
internal DSL on Python. Waf takes aspects of this further and makes 
Autotools look a bit ill. There is a natural balance 

Go delegates to a DVCS all dependency issues, everything build-wise is 
totally by convention. It works but the hassle people are finding with 
repeatable builds leads to conventions as per gopkg.in.

Ant, hummm… started out as a platform independent version on Make, 
used XML for build specification and claimed to be declarative. 
Looking at Ant scripts these days, the hoops people go through to 
construct imperative programs in XML are amazing. The only alternative 
is to write a new task, which lots of people have to do.

Maven tried to go the project specification, and partly succeeded. 
Artefact repository approach a huge win. Specification in XML, yuk. 
Attempt at totally convention based build only partly worked. Lots of 
people have to write plugins to get the process they need for their 
goals.

Gradle fixed the transitive dependency tracking problems of Maven and 
has Groovy specifications. Yes there is a lot of purely declarative 
convention-based stuff, quite right too, but the ability to trivially 
add the extra bit of imperative in the build specification, stops the 
mess of Maven, Ant, CMake, Make.

SBT tries to use Scala as a project and build specification language. 
For simple projects, a few declarative lines are all that is needed. 
However for anything complicated you end up going outside the 
convention-only, but like Gradle and unlike Maven you can do this. 
SBTs major problem is Scala compile time for non-trivial project 
specification. Hence the need for a build daemon, a route Gradle has 
had to go as well due to infrastructure start-up time.

I could turn this into a better essay, but the above gives the main 
threads of the argument: project specification can be declarative, 
build specification is best as declarative as possible, convention-
based, but not totally declarative.

(I now I should mention tup here but I still haven't used it enough to 
know anything real about it.)

> Things may not (yet) be ideal, but fundamentally DUB is nothing more 
> than a tool built on a defined abstract package description format 
> (vs. a procedural build description). If you (or anyone else for 
> that matter)
> want to say that using a descriptive format is fundamentally flawed 
> then
> I'd be grateful for some additional substantiation. Otherwise there 
> is nothing "fundamental" in the system that I know of.

The fundamental problem here is that project specification and build 
specification is not either declarative or imperative.  From 1977 
onwards we have a trail of evidence that shows it is part declarative 
(as much as possible), but part imperative (as little as possible, but 
necessary for non-trivial projects).

Sticking with JSON as the only specification notation for Dub will 
inevitably lead people to have to hack or find another tool. The 
solution would be to either:

– Treat the JSON specification for dependency management only and use 
something else for build description so as not to be constrained by 
the only convention. 

– switch to an internal DSL so as to have mostly declarative but 
imperative as needed description of project, dependency and build 
process.


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150206/a54c37da/attachment-0001.sig>