The DUB package manager

[Jacob Carlborg]

On 2013-02-16 18:10, 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"}
>     }

Using a full blow language can look pretty declarative as well:

name = "my-library";
dependencies = ["mysql-native": ">=0.0.7"];

I don't see why something like the above would scare away people. It's 
even less code than the JSON above.

>     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.

I think it looks like you're tying the user to a particular build tool. 
I don't think it's the business of the package manager to build 
software. That's the job of a build tool. The package manager should 
just invoke the build tool. You just need to support a few build tools, 
like rdmd, make and then also support shell script.

Things like setting compiler flags does really not belong in a package 
manger.

I have not looked at the source code for DUB at all. In general how is 
it organized. Can it be used as a library to easily build, say a GUI or 
directly integrate into an IDE?

-- 
/Jacob Carlborg