Git, the D package manager

[Joseph Rushton Wakeling via Digitalmars-d]

On 02/02/15 09:09, Vladimir Panteleev via Digitalmars-d wrote:
> 2c. Versioning
>
> Git stores the exact commit of each submodule in the parent repository.
>
> So, if you make a commit in orchard/fruit/, and run `git status` in orchard/,
> git will show you that the "fruit" submodule has been modified.
>
> Most importantly, this means that any breaking change in the "fruit" library
> will never affect existing projects which use it, since they will continue to
> use the registered commit which was known to work.
>
> This gives you dependency versioning with commit granularity - you can hardly
> ask for something better - all without messing with configuration files.

This is both a benefit and a problem.

It's a benefit to the developer, who can specify exactly which version of the 
dependency they want used.  It's not necessarily good for the downstream user, 
because it requires that the developer actively maintain the dependencies.

Scenario: a dependency has a security hole that gets patched.  If the dub 
package is updated, all applications using that dub package will automatically 
have that update available next time they are built.  With git submodules, the 
developer has to recognize that update has happened and tweak the git submodule 
in the master project, and others downstream have to realize that has happened.

Git submodules are great for precise control of dependencies, but there are 
circumstances where it's preferable for upstream to be able to release new 
versions without them being filtered in this way.  I'd readily use git 
submodules in scenario where I controlled all of the code (including what was in 
the submodules), but not where I had external dependencies.

> 2d. Git vs. Dub
>
> Unfortunately, the above-described approach is not compatible with Dub:
>
> - Dub packages are generally expected to have their source code in a "src"
> subdirectory, although you can set the source directory to "." in the
> configuration file.

Actually, I think it's 'source'.  But either way, it's just enforcing a good 
layout practice, that can be reworked with the config file.  There is however 
some benefit to imposing a standardized project layout.

> - When cloning repositories, dub does not preserve the repository's directory
> name (so e.g. fruit will be cloned to ~/.dub/fruit-1.0.0/).

Necessary in order to maintain multiple versions of a package in order to 
satisfy different applications' dependencies, surely?  You have a similar 
situation with different versions of shared libraries installed on any UNIX system.