Git, the D package manager

[ponce via Digitalmars-d]

So. I've reported lots of bugs in DUB and fixed some, and since 
using it I never looked back. It does seem more stable these days.

On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev 
wrote:
> So, in order to start using Dub, I'd need to:
>
> - restructure the directory layout of my library (breaking 
> change)

I was about to say "yes" but perhaps that's fixable in DUB.
Currently, using ae checkouted in an ae/ directory means having 
an "import leak" meaning that you have to import a path outside 
the checkouted repositery. That's somehow unhygienic like, er, a 
global namespace. But yeah DUB could isolate checkouts one 
directory deeper (ae-1.0.0/ae/) to make this a non-problem, this 
would support libraries like ae/ and make DScanner work.

> - update all projects which use this library to use Dub instead
And drop their current build system for something hopefully more 
uniform and not that complicated.

> - give up quick syntax checking
Fixed it you push code one directory further.

> - give up commit-granularity versioning
Not necessarily if you make tags at each commit (and most of the 
time it's not really necessary).

> - begin maintaining JSON configuration files
It's not that bad honestly. Actually mandatory field are few and 
between. If using sub-packages it does take some learning though.

> - begin versioning libraries by hand
Yes, but with the benefit of:
- helping your users choosing a version, and protecting them from 
churn (eg. broken build)
- choosing if they want breaking changes.
- see also: 
http://forum.dlang.org/post/nknzdktahezyztzdvwpz@forum.dlang.org 
for the diamond dependency problem.

git submodules work well when you don't use third-party libs but 
let's be honest, not everyone understand git submodules let alone 
want to. I also know some D programmers that don't want to touch 
git.

> 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.

The DUB way does take more work and requires some learning but it 
makes things super simple for library _users_ and imho this 
benefits the ecosystem as a whole. If you want more users then 
DUB is nicer to them.

I've also found it changed my way to develop, I'm much more 
likely to reuse something from the registry, and much more likely 
to bundle breaking changes together.