On Tue, 06 May 2014 20:35:12 GMT, Andrej Mitrovic wrote:

On Tue, 06 May 2014 16:24:02 +0200, Sönke Ludwig wrote:

BTW, using sub packages (or separate packages) would be conceptually
cleaner for examples than using configurations.

AFAIK separate packages means the user has to CD all over the place.

As for sub packages, well samples aren't really packages, they're sample code. Additionally they should be easy to refer to and easy to build.

If the project name happens to be opengl-tutorials I don't want the user to be forced to type dub --config=opengl-tutorials:tutor1, they'll develop carpal tunnel syndrome having to type all of that.

Configurations are meant to represent different variants of the same program/library. Samples are separate, free-standing programs, so they should conceptually be free packages (even if not a root package that would be registered on the registry). When they are sub packages, they can be compiled as dub root-pack:tutor1*. When they are free standing packages, indeed either cd path/to/example && dub is necessary, or dub --root=path/to/example.

From the users view I think the best solution would be to use path based sub packages. They are quick to reference, but have their package description in a separate file, which provides a nice example for the user for how to build their own package. So it would look like: 

{
    "name": "library",
    ...,
    "subPackages": [
        "examples/tutor1",
        "examples/tutor2",
        "examples/tutor3",
    ]
}

{
    "name": "tutor1",
    "dependencies": {
        "library": {"path": "../../", "version": "~master"} // **
    },
    ...
}

BTW, instead of --config=value, there is also the short option -c value.

* New feature planned for the next release: Allow dub :tutor1 to be used to refer to sub packages.

** The "version" field is just necessary for compatibility with older DUB versions that stupidly always required a version specification.