The DUB package manager

[Sönke Ludwig]

Am 02.03.2013 09:19, schrieb Jonathan M Davis:
> On Saturday, February 16, 2013 18:10:21 Sönke Ludwig wrote:
>> With the recent talk about Orbit, I thought it is time to also announce
>> the package manager that we have been working out based on the simple
>> VPM system that has always been in vibe.d. I don't really like stepping
>> into competition with Jacob here (*), but the approach is different
>> enough that I think it should be put on the table.
> 
> I justed messing around with dub on one of my projects, and at first glance, I 
> like what I'm seeing. Hopefully, it'll be a good replacement for the ad-hoc 
> build setups that I typically use. However, while the package format 
> documentation seems to be fairly complete, the usage documentation is still 
> sorely lacking:
> 
> http://registry.vibed.org/usage

Agreed, there also needs to be a brief introduction how dub accomplishes
to usual tasks.

> 
> As it stands, I don't even have a clue what the various directories that get 
> generated are for, let alone something like how the docs target is supposed to 
> work (I just get errors from it about one of the files it generates not being 
> executable).

The "docs" target was just a quick draft added to have meaningful list
of standard built types and hasn't really been tested. I'll fix it right
away.

> 
> There should also probably clear examples of how to set up an application vs a 
> library. It seems to want to set up an application by default, and I assume 
> that you make it a library by mucking with dflags in the configuration file, but 
> how that jives with having an executable with -unittest, I don't know.

As it stands, there are just two modes of operation:

1. invoking dub on a project will build it as an application (any
"source/app.d" file is assumed to contain the main() function)
2. any dependent package is assumed to be a library and gets compiled in
without its "source/app.d" file.

This is currently tied to the simplified workflow that I use. Although I
find this to be a quite nice approach in general and it covers most uses
nicely, support to specify explicit library types will be added later.

> 
> And if dub is supposed to work with build scripts or other build tools as some 
> of your posts here imply, then that definitely needs to be documented, because 
> I don't see anything of the sort.

It's not yet implemented, although trivial.

> 
> So, it looks like it has a good start, but without better instructions, it's 
> going to be a bit hard to use it properly it seems.
> 

Right now everything has to be extended a bit to handle the different
use cases and project structures that came up until now in a comfortable
way. I hope this to settle down in one or two weeks and then I'll write
up a proper introduction on that page and make a quick announcement.