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

Sönke Ludwig sludwig at outerproduct.org
Wed Sep 11 04:30:06 PDT 2013


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.

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

Why not _make_ a tag? But uploading zipped packages (or better 
specifying an external link) could be added as an alternative without 
much effort.

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

This is something that may still need some adjustments, but after all 
it's just a default when there is a "source/app.d" or 
"source/<packname>.d" file - an explicit "targetType": "xxx" will fix it 
when it's off.

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

"views" is maybe not general enough, but for what it's worth I'm also 
using it on other kinds of projects (e.g. to specify GUI templates). 
"res" might be a bit *too* general, but this could for sure be improved 
somehow. "public" is indeed specific for web stuff, so it may be the 
best to drop it by default.

I've also thought about offering a set of template projects usable for 
"dub init", so that there could e.g. be a true vibe.d skeleton, but by 
default it would be a minimal project with only a "source" folder.

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

Note that there is "dub describe" to extract the information relevant 
for actual building plus there is "dub generate xxx", so nothing is in 
the way of using a separate tool for building. But having integrated 
building IMO is highly convenient and keeping the build description in a 
standardized format is one of the key selling points.

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

You can put an additional "bar": "==0.0.1" dependency in the main 
package to lock it to a certain version. Or, of course, just use "==" in 
the bar package in the first place. This could also be implemented as a 
(semi-)automatic function along the lines of "dub lock-versions" and 
"dub lock-versions --upgrade".

On the other hand it's difficult to make a general statement that this 
is always the best way as this may for example prevent important 
security fixes to get incorporated unless the main package maintainer 
releases an explicit update...

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

I'm quite confident that most points are not in conflict with the 
existing functionality and can be resolved just fine. Only the 
build/package combination is something that is too deeply rooted in the 
projects philosophy to just drop it. But it can be kept opt-out as far 
as possible and shouldn't harm special use cases.


More information about the Digitalmars-d mailing list