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

Reply via email to