Git, the D package manager

[Atila Neves via Digitalmars-d]

This is really good feedback, thanks. Would you be interested in 
discussing this further privately? I've already got some ideas 
brewing in my head.

Atila

On Tuesday, 3 February 2015 at 18:00:31 UTC, Russel Winder wrote:
> 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/