The DUB package manager

[Rob T]

On Saturday, 16 February 2013 at 19:35:47 UTC, Russel Winder 
wrote:
> On Sat, 2013-02-16 at 20:15 +0100, Jacob Carlborg wrote:
> […]
>> I'm thinking that there should be a build tool that drives 
>> everything. The build script contains package dependencies. 
>> The build tool will ask the package manager to get 
>> linker/import paths and libraries for the dependencies.
> […]
>
> First a plug for people to think of SCons and Waf, not to 
> mention
> Gradle, when starting to rattle of build tools.
>
> The SBT folks are using Scala in quite interesting ways to 
> enable Scala
> to define project specifications with all the non-inferable
> dependencies.
>
> The Gradle folks have already done almost everything the SBT 
> folks are
> doing, but using Groovy rather than Scala.
>
> The Go folk have done something interesting in that they have 
> merged the
> whole concept of configuration and build by doing everything 
> over DVCS.
> You put your sources in Git, Mercurial, Bazaar (they really 
> should
> include Fossil as well but…) and these can be Got and the 
> modules
> created within the standard structure local hierarchy.  The 
> have a
> single command that performs all activity. D has rdmd but 
> compared to
> Go's go command it cannot do a lot.
>
> I would suggest now is the time to think outside the box, 
> analogous to
> the ways the Gradle and SBT folk have on the JVM and the way 
> the Go folk
> have for native builds of statically linked code.
>
> Instead of thinking in terms of compile, link, modules, 
> dependencies,
> what is the workflow that makes D the compelling language for 
> building
> Fortran/C/C++/D systems. This is suggesting that the milieu to 
> attack is
> the one currently being won by Python in the computationally 
> intensive
> areas of bioinformatics and scientific computing.
>
> Can D be the project specification language using convention 
> over
> configuration. Project directories are in a standard form (with
> exceptions describable) with dependencies either inferred by 
> scanning
> the project sources or specified in a trivial way in the project
> specification file.
>
> Thus I suggest that it is not that the build tool is embedded 
> in the
> package manager but that package and dependency management is 
> part of
> the build system.

I'm having good success using D itself as the build tool 
language, and I'm at the point now where I'm getting much better 
results than what I was getting out of using external build 
tools, so for me there's no looking back.

I run rdmd on a .d "script" that I wrote that's setup to do 
exactly what I want.

What is missing from D is a good library of functions that are 
generally useful for writing build scripts. Phobos already 
supplies a great deal of what is needed that can be used to 
construct what is missing.

The benefit of using D is that I do not have to install and learn 
a secondary language or conform to a specific build format, or 
follow any weird restrictions. What I want to do is build my D 
code, not learn something new and perform acrobatics to get the 
job done. I can even use the same D process to build C/C++ code 
if I wanted to expand on it.

What I'm saying here is that I see no reason to use a language 
other than D itself as the build tool. What D can use is an 
addition to Phobos that supplies the necessary generalized 
functions that all build tools should supply, and I don't think 
there's all that much that's missing.

For a package manager, some standards may be required, but it too 
can be done completely with D.

Why use json (which is a subset of javascript), or ruby, or 
python, etc? Is there something fundamentally wrong with D that 
makes it unsuitable for this role?

--rt