It's easier to get started without getting tied down by an
existing codebase, for one. But you've got me thinking: if I do
anything I should do it as a library first and foremost to make
its possible future inclusion into dub a lot easier. I hadn't
considered that.
I was also thinking of not adding complexity to dub, but I guess
most other language-specific package managers do double duty as
build tools as well. How well they do that moonlighting job is
another matter.
In any case, I don't want to replace dub; I want to use it for
package dependencies for those who want to build their software
that way. I also want to enable local filepaths and
github/bitbucket/whatever direct links, kind of like what "go
get" does, for use-cases like Vladimir's. Oh, and C/C++
integration. That's the idea I had yesterday anyway.
Atila
Why not invest your time into improving dub and adding these
features, we don't need another tool. Improving dub would have
a much bigger impact than making another tool that is almost
certainly never going to get used because very few tools ever
get to that level.
Honestly it seems like a huge waist of time and very counter
productive.
