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

[Bruno Medeiros]

On 11/09/2013 12:30, Sönke Ludwig wrote:
> Am 11.09.2013 11:57, schrieb Jacob Carlborg:
>> On 2013-09-10 22:48, Andrei Alexandrescu wrote:
>>> We've been experimenting with http://code.dlang.org for a while and
>>> things are going well. In particular Sönke has been very active about
>>> maintaining and improving it, which brings further confidence in the
>>> future of the project.
>>>
>>> We're considering making dub the official package manager for D. What do
>>> you all think?
>>
>> Unfortunately I have to say no to its current state.
>>
>> The biggest issue I have with dub is that it's really doesn't install
>> packages, at least not in the traditional sense. I cannot just run "dub
>> install foo" and then "foo --help". It will only clone the repository,
>> not install, or install anything. It basically only supports source
>> packages, which makes it mostly useless for tools/application compiling
>> to executables.
>>
>> I would say, compiling and installing executables is a must. It would be
>> nice if it could compiling libraries as well.
>
> Right now it is a pure development tool. It would be very nice to have
> end user installs somehow supported (either by directly installing
> application packages or by generating OS specific packages such as DEB
> or RPM). But since this enters a highly operating specific area and goes
> into direct competition with the OS package manager, I think it needs a
> lot of thought and caution to be generally useful and not possibly do
> more harm than good in the end. But yes, it should be a primary goal in
> my opinion, too.

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

What dub should be first and foremost is a structured build tool (and 
build specification) for D projects.

-- 
Bruno Medeiros - Software Engineer