Git, the D package manager

[Russel Winder via Digitalmars-d]

On Mon, 2015-02-02 at 16:50 +0000, Atila Neves via Digitalmars-d wrote:
[…]
> 
> I have ideas that go beyond this, but this is useful input. I 
> wonder how to proceed now about gathering actual requirements 
> from D devs and seeing which ones are important.

Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.

Some Scala folk got religious about Scala being the only right language
for Scala builds, and created what has become SBT. Because of the way
statically typed Scala works as a domain specific languages there are
performance and expression issues that means SBT is getting a reputation
in the very companies that should be supporting it that it is "the
enemy".

A D build system must trivially support C, C++(, and Fortran?).

Transitive dependency management needs careful consideration. I haven't
investigated whether Dub does this right, it may well do. Maven does
not, Gradle does.

Define package, artefact, dependency carefully. Go has a strong model
(even if it is wrong). Ceylon improves on Java/Scal/etc. Python got it
woefully wrong: eggs were a mess, and PyPI is not curated well enough
(the vast majority of stuff on PyPI is unusable rubbish).

Worry about platform specific packagers: MacPorts, Homebrew, Debian,
Fedora, FreeBSD, OpenBSD, etc. will (hopefully) want to package. Java is
generally a disaster for them, and Python isn't that much better. Go is
ignoring al this and creating a monoculture based on Git and Mercurial
as packages are shipped as source. I see Debian and Fedora trying to
package Go things and predict the same mess as Java and Python.

Support principally a declarative DSL, but with imperative structure
possible. A build specification is a meta-program which when executed
creates the program and hence the build process.

Have no clearly silly constraints, cf. the needs for SBT specification
lines always to be separated by blank lines.

Be convention over configuration, but allow configuration.

Use BinTray and Artifactory as well as the current Dub repository.

Do not be afraid to change the meta-data specification so that. Dub may
well be a good start, but it may need work. Gradle has changed it's
meta-data specifications many times despite being constrained by
compatibility with Maven POMs and Ivy specification.

Stand on the shoulders of giants, but do not assume they are always
right, be prepared to change stuff for the better.

Get alpha testers in early and let them drive things – albeit within the
boundaries of your vision for the system. Dub did well here if I
remember correctly and created a group of people who did and emailed
rather than just emailing. 

I better finish my essay at this point I have a London D User Group
meeting to go to :-)

http://www.meetup.com/London-D-Programmers/


-- 
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