Git, the D package manager

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 5 08:32:27 PST 2015


Am 05.02.2015 um 16:15 schrieb Vladimir Panteleev:
> On Thursday, 5 February 2015 at 14:48:24 UTC, Sönke Ludwig wrote:
>>> - restructure the directory layout of my library (breaking change)
>> Not true. Use "sourcePaths" and "importPaths" to configure the package
>> as appropriate.
>
> Right now this is necessary to maintain directory/package path consistency.

(Still reading the thread) If you mean that fetched packages are stored 
within "<packagename>-<packageversion>" folders, that's true of course, 
I didn't think of that. So it wouldn't work for a publicly registered 
package, but it would still work if you just use the library as a git 
submodule, or using some other kind of checkout protocol that keeps the 
original folder name. I think we should look into a fix here, such as 
using "<packagename>-<packageversion>/<packagename>".

>
>>> - 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.
>
> I think the only build script I had to write was for RABCDAsm, which
> probably can't be reimplemented as a dub.json file:
>
> http://forum.dlang.org/post/peurhbfebwdskcballzk@forum.dlang.org
>
> For DFeed and a few small projects I use Makefiles and packaging
> scripts, but they also do more complicated things such as signing
> Windows executables, compressing/compiling resources, and applying
> .manifest files.
>
> In general, I've tried to make things work with rdmd alone.

Okay, things like testing for DMD bugs and signing stuff would indeed 
still have to be done outside of DUB using a separate 
pre(Build/Generate)Command (a failing command should automatically stop 
the build), but at least the dependency management part (haveLZMA) 
should map fine to DUB packages.

I agree that if you only look at it in this context, that DUB may look 
like a useless complication (two build scripts/files instead of one). 
The real advantage comes when things like complex dependency trees or 
IDE project files get involved.

>
>>> - 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.
>
> I can see how that is more practical for public libraries. Commit
> granularity helps if you want reproducible builds, though.

Fun fact: If you register a GIT working copy using "dub 
add-path/add-local" and it doesn't have an exact tag checked out, then 
any package that uses it, will have something like this in its 
dub.selections.json file: '"vibe-d": "0.7.22+commit.17.g75ecb6b"', where 
"0.7.22" is the latest version tag on that branch and the suffix is the 
current commit hash.

This information is currently not used to drive GIT and automatically 
check out that same commit before building. But we could of course 
implement that in one form or another to have fully reproducible builds 
with commit granularity.


More information about the Digitalmars-d mailing list