RejectedSoftware Forums

On Mon, 05 May 2014 21:03:23 +0200, Sönke Ludwig wrote:

Specifying "sourcePaths": [] explicitly should make that work.

Just tried it, but no dice. I guess it's not implemented?

Am 06.05.2014 14:47, schrieb Dicebot:

On Mon, 05 May 2014 20:09:01 GMT, Andrej Mitrovic wrote:

On Mon, 05 May 2014 21:03:23 +0200, Sönke Ludwig wrote:

Specifying "sourcePaths": [] explicitly should make that work.

Just tried it, but no dice. I guess it's not implemented?

I have noticed that you need to define empty source paths globally to be able to completely override it in configurations: https://github.com/Dicebot/examples/blob/master/dub/proj1/dub.json

Right, the ones for configurations are additive.

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

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.

Am 07.05.2014 12:12, schrieb Andrej Mitrovic:

On Wed, 07 May 2014 06:56:59 GMT, Sönke Ludwig wrote:

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.

I guess this is ok since the user might want to be able to run dub when they're inside a sample directory.

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

That would be nice! A related feature I kind of want is the ability to write aliases so I can write things like:

"aliases:": {
     "tut01": "opengl-tutorial.org:tut01",
},

And then run:

dub run tut01

Aliases might be a good feature for other things, e.g. if you want to rename things but want to keep backward compatibility for a while (I guess emitting a deprecation message would also be appropriate if an alias is marked as deprecated).

Okay, for now the :tut01 syntax works. I'm not yet sure what the
possible caveats of a general alias feature would be (conflicts etc.).
Package deprecation could also be done by keeping a dummy target type
"none" package that just has the new dependency name as the only dependency.