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.
