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

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

Some other minor issues:

* The registry automatically tracks the git repository. If I register a 
new project it will default to "master" if no tags are available. I 
would prefer to tell the registry myself what's available.

* By default a package has the target type "autodetect" which will try 
and build an application and a library, as far as I understand it. Many 
projects cannot be built as an application, they're just libraries. Or 
the other way around.

* When running "dub init foo" you get a directory structure like this:

foo
   |
   |__ public
   |
   |__ source
   |   |
   |   |__ app.d
   |
   |__ views
   |
   |__ package.json

This directory structure is very centered around vibe.d. This was fine 
when dub was primary the package manger for vibe.d, but I don't think it 
should look like this if it becomes the default package manager for D. I 
mean, "public" and "views", why would I need those. As I understand it 
"views" can be used for string imports, in that case it would be better 
to call it "res" or "resources" instead. Most non vibe.d projects would 
probably not need this at all so I'm not sure if this should be default.

* Tries to be a build tool and a package manager and at same time

* I'm not sure how it installs indirect dependencies. I'm suspecting it 
will always install the latest version of an indirect dependency if 
nothing else is specified, which I think is really bad for systems in a 
production environment. When the project is built it should locked down 
and all the versions of the dependencies, including indirect dependencies.

Say I have a package file looking like this:

{
     "name": "myproject",
     "dependencies": {
         "foo": "0.0.1"
     }
}

And

{
     "name": "foo",
     "dependencies": {
         "bar": ">= 0.0.1"
     }
}

And

{
     "name": "bar"
     "dependencies": {
     }
}

The latest version of "bar" is 0.0.1.

When building "myproject" it should lock down "bar" to the latest 
version matching the requirement, that is 0.0.1.

If a new version of "bar" is out, say 0.0.2, and I'm then installing 
"myproject" on a different computer, I should get the exact same 
packages, that is "bar" should be at version 0.0.1.

If I want a later version of "bar" I should explicitly tell dub that.

In the end I think it's great if we get a package manager for D. But in 
its current state I'm not overly enthusiastic about dub. But depending 
on what other thinks and Sönke is willing to take some of this into 
consideration I think it could be a good addition to the D tools.

-- 
/Jacob Carlborg