The DUB package manager

[Sönke Ludwig]

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.

Some may already have noticed it as it's mentioned already on the vibe.d
website and is currently hosted on the same domain as the old VPM registry:

http://registry.vibed.org/


DUB has two important development goals:

 - Simplicity:

   Making a DUB package, as well as using one as a dependency should be
   as simple as possible to facilitate broad usage, also and especially
   among language newcomers. Procedural build scripts often scare away
   people, although their added complexity doesn't matter for bigger
   projects. I think they should be left as an option rather than the
   default.

   Turning a library/application into a DUB package can be as simple as
   adding a package.json file with the following content (mysql-native
   is automatically made available during the build in this example):

   {
        "name": "my-library",
        "dependencies": {"mysql-native": ">=0.0.7"}
   }

   If the project is hosted on GitHub, it can be directly registered on
   the registry site and is then available for anyone to use as a
   dependency. Alternatively, it is also possible to use a local
   directory as the source for a particular package (e.g. for closed
   source projects or when working on both the main project and the
   dependency at the same time).

 - Full IDE support:

   Rather than focusing on performing the build by itself or tying a
   package to a particular build tool, DUB translates a general
   build receipt to any supported project format (it can also build
   by itself). Right now VisualD and MonoD are supported as targets and
   rdmd is used for simple command line builds. Especially the IDE
   support is really important to not simply lock out people who prefer
   them.


Apart from that we have tried to be as flexible as possible regarding
the way people can organize their projects (although by default it
assumes source code to be in "source/" and string imports in "views/",
if those folders exist).

There are still a number of missing features, but apart from those it is
fully usable and tested on Windows, Linux, and Mac OS.


GitHub repository:
https://github.com/rejectedsoftware/dub
https://github.com/rejectedsoftware/dub-registry

Preliminary package format documentation:
http://registry.vibed.org/package-format


(*) Originally I looked into using Orbit as the package manager for
vibe.d packages, but it just wasn't far enough at the time and had some
traits that I wasn't fully comfortable with.