The DUB package manager

Sönke Ludwig sludwig at outerproduct.org
Sun Feb 17 00:02:24 PST 2013


Am 16.02.2013 23:58, schrieb Rob T:
> 
> 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.

I did that, too, for automated and Linux builds. But this means that if
you also want to work with an IDE for debugging and such things, you
have to keep additional project files in sync. The DUB approach just
combines the two (+ the package management) and also has less overhead
than doing it with D (main function, imports, possibly distributing
helper modules etc.).

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

But you will have to learn the API of the build script helpers, too. I'm
not sure if this is actually less to learn than the JSON alternative.

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

Well, DUB is fully written in D, so the question is less D or not, but
more if an additional intermediate layer for the package description
makes sense or not.

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

I see the following points for the decision for data/JSON vs. D:

 - Meta information needs to be available to the package registry and
for managing dependencies in general. Executing a script/program would
imply a big performance risk, and worse, is a high security risk in case
of the registry. So a data-driven approach is needed at least for the
meta data anyway.

 - JSON is a nice standard format with generally low risk of errors. I
agree that it is not the prettiest language in the world (although IMHO
much better than something XML based). Generally the same recent
discussion on the beta list for the dmd.conf format applies here, I'm
not sure what is the best approach, but JSON at least is not too bad.

To me the most interesting open question is this: Do we actually gain
from programmatic support for the build description, or does it suffice
to have a good purely descriptive system? If the former should be true
for more than 1% of the cases, that would definitely be a good argument
against pure data.



More information about the Digitalmars-d mailing list