Git, the D package manager

[Andrei Alexandrescu via Digitalmars-d]

On 2/8/15 3:00 AM, Jacob Carlborg wrote:
> On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
>
>> 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".
>
> It's kind of the same in the D community. Before Dub existed I started
> to work on both a package manager (Orbit) and a build tool (never
> officially announced). I used Ruby as the description format for package
> files a build scripts. Ruby is a language which allows you to create
> DSL's both with a declarative syntax and still support imperative code.
> Example:
>
> target :foo
>
> if System.osx
>    target :foobar
> end
>
> Of course that was completely reject since it was Ruby and not D.
> Although, for some reason Make is acceptable in the D community. It's
> basically only D or a markup language that will be accepted.

Ehm. This part sounds unnecessarily a bit political - NIH syndrome, 
closemindedness of the D folks toward using anything else but D and 
make, and such.

I do remember one action I took "against" Ruby - replacing a 109 line 
Ruby installer script with 13 lines of makefile code: 
https://github.com/D-Programming-Language/installer/pull/10/files. It 
would be difficult to construct an argument against that work.

Ruby and Python have all my respect as an outsider of their respective 
communities: they have users who enjoy them and get work done using 
them. That's always a good thing in my book.

That said, I wouldn't feel easy appealing to Ruby or Python for D 
internal work for reasons that I consider entirely practical and 
non-political:

* One more language for the maintainers to know and use.

* One more dependency. Although scripting languages are ubiquitous 
enough, I can tell from direct experience that versioning and dependent 
packages can be quite a hassle.

* Escaping into a high-level language seems as much "cheating" as 
escaping into a low-level language. If C or C++ would be needed instead 
of D for a task, it is worthwhile exploring how to make D a better 
replacement for them . This has been historically a good and important 
goal to pursue. Similarly I'd rather explore what it takes to expand D 
into high-level territory instead of escaping into a high-level language.


Andrei