The DUB package manager

[deadalnix]

On Saturday, 16 February 2013 at 17:10:33 UTC, 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.
>
> 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.

So I'm sorry if that appears completely stupid, but . . .

DUB sounds kind of like dumb. As Orbit sounds very nice, 
especially since libraries are satellites of mars, so it make 
sense to see other libs as artificial satellites :D

That is very poor, and have nothing to do with the actual 
capabilities of each of them.

BTW, it's be great is we could avoid some king of phobos/tango 
split on that subject and settle on one package manager.