Git, the D package manager

[Sönke Ludwig via Digitalmars-d]

Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
> Even if I had faith that dub was a perfectly polished piece of software,
> it doesn't solve any problems I have with building D programs, and in
> fact would make said task more complicated. Here's why.
>
> (...)

I think I've already answered most of the points in other replies, so 
I'm just going to skip to the final list of claims.

> So, in order to start using Dub, I'd need to:
>
> - restructure the directory layout of my library (breaking change)
Not true. Use "sourcePaths" and "importPaths" to configure the package 
as appropriate.

> - update all projects which use this library to use Dub instead
Not true. Adding a dub.json will probably not break any dependent projects.

> - give up quick syntax checking
Not true. Use path based dependencies or "add-path"/"add-local" to 
reference dependencies wherever you want.

> - give up commit-granularity versioning
True. However, this can be fixed. Direct GIT/HG support is already on 
the list of nice to have features.

> - begin maintaining JSON configuration files
Well, for most projects that would mean writing a tiny JSON file once 
and never touch it again. If you commit to it, you can of course stop 
maintaining a D build script, so I'm not sure how much of an argument 
this is.

> - begin versioning libraries by hand
A good thing, IMHO! Commit hashes alone have no semantical meaning, 
which is problematic for public libraries for many reasons. For private 
libraries things can be different and additionally supporting commit 
based dependencies may be good to have.

> - install Dub on all my computers, servers, and virtual machines
Yes. You could then skip installing GIT, though ;)

>
> No thanks.
>
> I could invest time in improving Dub to fix or ameliorate some of the
> above points, but I don't see a compelling reason to. In fact, I think
> we should integrate rdmd into dmd - dmd clearly already knows which
> source files participate in compilation, as all rdmd does is basically
> take dmd's output and feed it back to it. This will greatly speed up
> compilation, too.
>
> Change my view.

DUB in it's current form focuses on three primary points:

  - Building a package should "just work", including building the 
dependencies (mind the bugs)
  - Provide a public package registry with minimal effort to register 
and maintain packages
  - Minimize the barrier to entry for "usual" projects

The more advanced use cases, such as interfacing with other languages, 
will be the focus of future development. The initial primary goals above 
have been chosen to be most helpful for language newcomers, so that we 
get the maximum gain for the language ecosystem as a whole (in terms of 
growth and barrier to entry). More advanced users and users with legacy 
code bases are of course just as important in the long run, so those 
concerns need to be addressed now, too (as developer resources permit).

Regarding a DMD integrated version of RDMD, I always have thought the 
same. If that were the case, using a recursive build strategy would 
definitely be the mode of operation for DUB, too. The reason why it 
works differently today is simply that it has to support all the build 
systems/project file formats of the supported IDEs/build systems and 
most of them work in a classic C++-like way with a list of source files.

IDE support was also one of the primary goals, because there are large 
groups of developers that exclusively develop with IDEs and forcing them 
to the command line would simply make it much more likely that they 
won't use D at all. On top of that I personally very much like the 
ability to quickly build with Visual Studio to use its graphical debugger.