Git, the D package manager

[Mathias LANG via Digitalmars-d]

On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev 
wrote:
> In contrast, Dub's default modus operandi is to blindly send to 
> the compiler all *.d files found in the "src" folder, whether 
> they're actually used or not. Not only can this be slower if 
> not all modules are always used, but it also won't work if the 
> source code contains multiple entry points, forcing you to 
> write complicated configuration files (i.e. do the computer's 
> work for it).

To be more specific, dub won't let you compile a project with 
multiple definition of a function. How is that a liability ?
Is rdmd able to build static and dynamic library ? If so, does it 
ignore files that are not imported anywhere ?

> 1b. rdmd and D's search path
>
> rdmd does not have any additional parameters to set up for 
> where it needs to look for source files, because it relies on 
> the compiler's search mechanism. Thus, if you can build your 
> program with rdmd, "dmd -o- program" will succeed, and usually 
> vice versa.
>
> In contrast, Dub builds its own search path using its JSON 
> configuration files, and has no equivalent of "dmd -o-".

I don't see any downside here.

> There is no simple way to syntax-check just one file in a 
> project when using Dub. I rely on this a lot in my workflow - I 
> configured a syntax-check key in my editor, which I use almost 
> as often as I save. A syntax check (dmd -o-) is much faster 
> than a full build, as it skips parsing other parts of the 
> project, code generation, and linking.

What's your editor ? Mine complains on syntax error.
If you're using vi/emacs, then placing your editor in source/ (or 
starting dmd here) would do the trick.

> 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.
>
> - 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/).
>
> Somebody has created a Dub package for my library (excluding 
> certain packages, due to point 1a above), and the other day 
> someone complained that it doesn't work with Dscanner, because 
> of the above issue - the module path "ae.dir.module" does not 
> correspond to the filesystem path "ae-1.0.1/dir/module.d".

git clone http://github.com/You/repo otherName

breaks that workflow equally. Relying on the name under which 
your repo was cloned doesn't seem that robust.

> So, in order to start using Dub, I'd need to:
>
> - restructure the directory layout of my library (breaking 
> change)
> - update all projects which use this library to use Dub instead
> - give up quick syntax checking
> - give up commit-granularity versioning
> - begin maintaining JSON configuration files
> - begin versioning libraries by hand
> - install Dub on all my computers, servers, and virtual machines
>
> No thanks.

- But then your library is self contained and won't break if 
someone has another workflow that makes him clone your library 
under a different name.
- That's the point.
- Addressed;
- Semver allows you to do much more, as mentionned before;
- It isn't much of a maintainance. You rarely edit dub.json once 
the base is set.
- dub rely on git tags for versioning. If you want to do *real* 
versioning (and not just "most up to date tag"), you'll still 
have to play with branches and submodules.
- Only your dev stations.

> Change my view.

Hope I helped :)