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
