On Wed, 02 Dec 2015 09:53:32 +0000, Russel Winder via Digitalmars-d wrote:

> On Tue, 2015-12-01 at 20:38 +0100, Sönke Ludwig via Digitalmars-d wrote:
>> 
> […]
>> Not currently. dub.sdl is not ideal, because it would lead to ambiguities within the dependency graph, but dub.selections.json could be extended to support that.
> 
> As Mathias pointed out putting the compiler choice in the dub.sdl file is actually not a good idea. I think leaving the dub.selection.json file as an automated file is probably best, it means it is disposable and recreatable easily without fear.

You mean dub.selections.json isn't intended to be end-user-modifiable? I keep getting warnings about deprecated branch dependencies that say I should use a version tag and, if I really want a branch, edit dub.selections.json to make it happen.

(This is mainly for ancient packages from before the semver times, most of which don't work at present.)

On Wednesday, 2 December 2015 at 12:03:50 UTC, Mathias Lang wrote:
> I'd personally like to have a `.dubconfig` settings, similar to how
> `.gitconfig` does it (same locations and lookup rules, e.g. ~/.dubconfig
> taking precedence over the global one). Some obvious candidates are the
> default compiler, where to store the package cache, the default file format
> to use, and the default values that gets used for copyright / author /
> license when running `dub init`.
> I guess this should be part of an issue :)

How about this goes in .dub/config.something (or following XDG, I don't know)

On Wednesday, 2 December 2015 at 16:50:28 UTC, Chris Wright wrote:
> On Wed, 02 Dec 2015 09:53:32 +0000, Russel Winder via Digitalmars-d wrote:
>
>> On Tue, 2015-12-01 at 20:38 +0100, Sönke Ludwig via Digitalmars-d wrote:
>>> 
>> […]
>>> Not currently. dub.sdl is not ideal, because it would lead to ambiguities within the dependency graph, but dub.selections.json could be extended to support that.
>> 
>> As Mathias pointed out putting the compiler choice in the dub.sdl file is actually not a good idea. I think leaving the dub.selection.json file as an automated file is probably best, it means it is disposable and recreatable easily without fear.
>
> You mean dub.selections.json isn't intended to be end-user-modifiable? I keep getting warnings about deprecated branch dependencies that say I should use a version tag and, if I really want a branch, edit dub.selections.json to make it happen.
>
> (This is mainly for ancient packages from before the semver times, most of which don't work at present.)

IMO it really should be auto-generated only, and fully determine the exact combination of package versions, so that it can be checked into SCM and be used to reproduce the same package state later on on a different machine.

But currently that's not the case, and the deprecated branch dependencies are only one reason for it. I think this needs a rethought. Ruby's bundler [1] is a system that works really well in my experience, and can serve as a model.

[1] http://bundler.io/

On 2015-12-02 21:26, Marc Schütz wrote:

> IMO it really should be auto-generated only, and fully determine the
> exact combination of package versions, so that it can be checked into
> SCM and be used to reproduce the same package state later on on a
> different machine.
>
> But currently that's not the case, and the deprecated branch
> dependencies are only one reason for it. I think this needs a rethought.
> Ruby's bundler [1] is a system that works really well in my experience,
> and can serve as a model.
>
> [1] http://bundler.io/

I pushed for following the Bundler model from the start. It was very difficult to try to convince the author(s).

-- 
/Jacob Carlborg