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