dub: should we make it the de jure package manager for D?

[Sönke Ludwig]

Am 13.09.2013 12:00, schrieb deadalnix:
> On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
>> We've been experimenting with http://code.dlang.org for a while and
>> things are going well. In particular Sönke has been very active about
>> maintaining and improving it, which brings further confidence in the
>> future of the project.
>>
>> We're considering making dub the official package manager for D. What
>> do you all think?
>>
>
> Several remarks (I'm a dub newbie, so it is mostly conditional stuff) :
>   - Can we manage repositories ? For instance can I use my company repo
> instead of code.dlang.org ? Can I use several repositories with some
> kind of priorisation ?

It supports specifying a list of registries that is searched linearly 
for packages in its config file (or as a command line argument) - I 
think I still need to document that, though.

The registry currently supports only GitHub and Bitbucket repositories 
to source packages from, but that can be easily extended by implementing 
the "Repository" interface.

>   - How does the tool handle several version of a package ?

In the current registry implementation, git tags of the form 
vX.Y.Z[postfix] are taken as the available versions. When specifying 
dependencies it's then possible to use relational operators to specify a 
range of acceptable versions, of which the newest is used. Things like 
the version pinning mechanism proposed by Jacob can still improve things 
in this area.

>   - What is the process to get some code on code.dlang.org ? We must
> settle something if this have to go "official".

My idea (the status quo) is to keep that as open as possible. Anyone can 
register an account and register his/her repository. Package names are 
reserved on a first-come-first-serve basis. This process would then be 
augmented with community votes, automatic package deprecation and 
sporadic moderation to keep everything clean in the long term.


>   - What is the dependance management strategy used ? How does it
> resolve conflicts ?

There are basically three areas where things can conflict AFAICS:

  - Accepted version ranges for packages that are referenced by multiple
    other packages: Here the best version that satisfies all given
    ranges is used if possible, otherwise error out

  - Selected configuration for a package: This is resolved to the first
    possible set of configurations if possible, otherwise error out
    (this is a bit more complex due to the platform playing a role in
    configuration selection)

  - Conflicts in code (i.e. module/package name clashes) - This is
    currently not handled, but there have been discussions about that
    topic:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1/