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

[Jacob Carlborg]

On 2013-09-25 17:51, Bruno Medeiros wrote:

> Whoa, no. Application/executable install management as a goal would be a
> ridiculously bad idea.
> Because that would sit at the wrong abstraction level. The OS package
> manager should not be tied to a particular language to compile packages
> from. Does it makes any sense to have to use D's package manager if my
> cmd-line util is written in D, but if I have a C++ or Go derived
> executable, I would have to use a different package manager for each?
> And what if I want my tool to depend (at runtime) on an executable
> generated from another language? Devise a mechanism for
> cross-package-manager interoperaction?...
> Ridiculous. An application/executable manager should be language
> agnostic (and not even require compilation).

Instead I need to package my application and libraries for all the 
various of package managers out there. Not to mention neither Mac OS X 
or Windows comes with a package manager installed by default.

It's like buying a car. I buy a car for getting from A to B. I have 
bought my car and prepares to get from A to B. The car won't start, hmm 
..., oh it has no engine. I have to figure out myself how to buy and 
install the engine. It's only half way there.

It's the same with dub. I install a package to use the tool. But wait, 
it actually _don't_, it just clones the repository.  I have to figure 
out myself how to compile and install the tool. It's only half way there.

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

-- 
/Jacob Carlborg