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/nknzdktahezyztzdv...@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.
