dub: should we make it the de jure package manager for D?

[Bruno Medeiros]

On 26/09/2013 07:57, Jacob Carlborg wrote:
> On 2013-09-25 17:51, Bruno Medeiros wrote:
>
> I have to figure out myself how to compile and install the tool. It's only half way there.
>

You have to install the yourself, yes. Not compile it. Dub should take 
care of the compiling aspect.
If you just want to use the tool executable artifact, dub is likely not 
right for you. If the tool requires more complex installation, the tool 
developers should provide their own installer or OS distribution package.


>> What dub should be first and foremost is a structured build tool (and
>> build specification) for D projects.
>
> There's nothing wrong with being a build tool. But currently dub tries
> to be way more than a build tool. I don't think a build tool should have
> any business in downloading packages, or download anything.
>

A build tool should not download anything? That is antiquated C/C++/make 
way of thinking. Popular build tools for modern languages all do 
downloading, for example Apache Maven (for Java), Gradle (for lots of 
different languages), and even RubyGems.
You might say RubyGems is a package manager, and not a build tool. But 
in practice it is both actually, even if it is not called a build tool: 
It fullfills the the equivalent goal as structured build tools like 
Maven or Graddle do for other language, the distinction is only less 
clear becase Ruby as a language can be easily interpreted and does 
require an overt "compilation/build" phase to generate an executable.

-- 
Bruno Medeiros - Software Engineer