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
