dub: should we make it the de jure package manager for D?

[Jacob Carlborg]

On 2013-09-26 16:16, Bruno Medeiros wrote:

> Are... you... serious?... O_O
>
> There are incredibly important benefits for development-time usage.
> To automatically fetch the required dependencies, making sure they are
> correct for you application. Easily upgrade the version of dependencies?
> Support multiple build configurations (including for example unittest
> runners)?


> Supporting all the previous functionality in a way that is
> replicable across different machines?

It's not, that's another big issue with dub. It doesn't lock the 
dependency graph. If you have the packages:

My own package:

{
     "name": "foo",
     "dependencies": {
         "bar": "=0.0.1"
     }
}

Third party package:

{
     "name": "bar",
     "dependencies": {
         "xyz": ">=0.0.1"
     }
}

Another third party package:

{
     "name": "xyz"
}

Say I install package "foo" on a machine. It will install package 
"bar-0.0.1" and "xyz-0.0.1" just as it should. Then an hour later I 
install the same package, "foo", on a different machine. Then suddenly 
it install "xyz-0.0.2". Surprise surprise, it's not the same application 
anymore and you have no idea if the application is working or not.

Of course, it's unlikely this will happen within an hour. But try six 
months later and you might end up with a completely different application.

> Have other tools such as IDEs  understand the source and build structure of your
> application/project/library??
>
> System package managers don't support this because they are not
> cross-platform. Even if cross-platform wasn't an issue, there might
> still be several shortcomings or inadequacies with OS package managers
> because they are more often geared torwards end-user installation, not
> development-time usage.

I'm not saying that all other features are not useful but I'm saying 
that it doesn't actually install the packages is a big issue.

-- 
/Jacob Carlborg