dub: dependency manager for D language

Difficulty finding the necessary libraries. Problems with the universal cross-platform build of the project. Separation and control of dependencies.

All of the above are often mentioned by newbies who are trying to use D as a significant obstacle to creating new projects. The popularity of such projects as NPM and Ruby Gems form certain expectations of modern programmers. At the same time, the world of natively compiled programs has its own specifics.

DUB is an attempt to create a similar tool for D programmers, a project that is very popular in the community and is likely to become official soon.

Description

DUB is:

• Building a project on various operating systems with a simple dub build
• Automatic loading of specified dependencies from the project register
• Dependency Version Control
• Publish your projects in the register for community use
• Ability to run local projects via dub run without clogging up the system
• Fully open infrastructure - nothing prevents you from running your project register or using local paths

At the same time, DUB does not provide tools for distribution and installation of programs among end users and is not a package manager in the full sense of the word. This tool is designed to facilitate the development process itself and focuses solely on this.
')
Initially, DUB was created by Sönke Ludwig as part of the vibe.d project, but after a while it was rewritten as an independent project and is currently the de facto standard for projects on D. It is assumed that from some moment the utility will be distributed with the compiler and get the status of a standard tool de jure - this idea has already been pre-approved by the authors of the language and the issue is only in more stabilizing the API / project format.

Installation

To install DUB, you can use one of the following options:

• Ready executable files: code.dlang.org/download
• Manual build from repository: github.com/rejectedsoftware/dub (just run build.sh )
• Arch Linux and Ubuntu / Debian Packages

By default, all temporary files and the registry cache are stored in ~/.dub or a similar directory of a local user; no administrator permissions are required.

Using

Project creation

The easiest way to create a framework for a new project is to use the init subcommand:

 dub init proj1 find proj1 # proj1/ # proj1/dub.json # proj1/source # proj1/source/app.d cd proj1 dub run # proj1: ["proj1"] # Building proj1 configuration "application", build type debug. # Compiling... # Linking... # Running ./proj1 # Edit source/app.d to start your project. 

The dub run command compiles and runs the current project according to the settings from dub.json , the project description file. Usually, all files from the ./source/ subdirectory are ./source/ , as well as the modules they import. The dub build does the same, but does not run the executable file.

Add dependencies

The key dub feature for which it was primarily written was the automatic loading of dependencies during compilation. To do this, specify the necessary libraries in dub.json :

 { "name": "proj1", "description": "A minimal D application.", "dependencies": { "vibe-d" : ">=0.7.18", "cerealed" : ">=0.5.0" } } 

All dependencies of dependencies will be downloaded implicitly. When you first build the application, the action log will indicate which dub packages download and where they are stored. In the future, it will use the local cache until the dependency version in dub.json or the dub upgrade command is explicitly called.

In the code of the application itself, you can import any modules from dependency libraries without any additional effort. Generating the necessary compiler flags is done by the dub itself.

 module app; import vibe.d; // just works 

Dependencies can be not only libraries, but also applications. In this case, they will be compiled before your project and available for use via dub:

 dub run <package name> <application arguments ...> 

Additional configurations. Testing.

The dub test command will compile and run all the unit tests of your application (meaning the native feature D: inline unittests ). However, you usually want to keep tests of a higher level, for example, integration tests, separately from the main application. This can be achieved using the dub.json feature such as configurations:

 { "name": "proj1", "description": "A minimal D application.", "sourcePaths" : [ ], "configurations" : [ { "name" : "app", "targetType" : "executable", "sourcePaths" : [ "./source" ], }, { "name" : "tests", "sourcePaths" : [ "./tests" ], "targetType" : "executable", "targetName" : "app-tests", } ] } 

 find ./ # ./dub.json # ./source # ./source/app.d # ./tests # ./tests/app.d dub build --config=tests dub build --config=app # default 

In essence, a configuration is simply a named block of options. In the example just given, the following parameter is used: dub.json , as sourcePaths - the list of directories with source codes for the used configuration. By default, this list always contains the "./source" directory, so you need to reset this parameter in the global section dub.json :

  "sourcePaths" : [ ] 

The first of the configurations in the list is always used as the default configuration, so it is practical to use it for the parameters of the normal assembly of the application. If only one configuration is used, of course, all these parameters can be simply specified in the global section.

Sample project sources can and should be touched: github.com/Dicebot/examples/tree/master/dub/proj1

More information

The above information should be enough to convert most simple projects. To meet real work needs, of course, you may need much more. Recommendations for further study:

The most complete description of the dub.json format: code.dlang.org/package-format
A selection of examples in the project repository: github.com/rejectedsoftware/dub/tree/master/examples
Questions / suggestions / requests: forum.rejectedsoftware.com/groups/rejectedsoftware.dub

... as well as ask questions here.

I must warn you that the entire infrastructure is being developed by the efforts of the community and the packages accessible through the register are not moderated. The best thing you can do when you find problems with a particular package is to write about it to the author or to get the corresponding Issue in the project repository.

Happy coding.