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/
