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
