This doesn't work when you have more complex dependencies, because they in turn have dependencies, which may clash. You have no way of knowing what pkg c version packages a and b expect when you include a and b.

If the dependencies clash, it doesn't matter what system you use. There isn't a package manager good enough to fix the issue of having conflicting dependencies.

Vendoring or cloning (with explicit upstream merging) is again your best bet for dealing with this as it the only way you have complete control of the dependencies involved.

If you are saying something like having a package X in your vendor lib that depends on packages Y and Z which you don't have vendored... then you haven't done it right. You vendor all dependencies.

I agree vendoring is essential in some situations, mostly in deployment to production or keeping tight control of libraries used in a project, but I disagree that versioning is not useful in a packaging system.

If you are saying something like having a package X in your vendor lib that depends on packages Y and Z which you don't have vendored... then you haven't done it right. You vendor all dependencies.

No, I'm saying imagine you have an app, which depends on pkgs a and b. a depends on c1.1, b depends on c1.5, but this is documented nowhere in the code because the import statements simply say import "c". This is the default and encouraged behaviour currently with golang and go get. go get a fetches the latest of c.

You then vendor a,b,c and happily compile your app, which doesn't work because the version of c you got when you vendored was 2.1, which neither a nor b was written against. Maybe your app will fail to build and you fix it, maybe your app will build but be wrong in subtle ways (say an enum value changed), without explicit versioning you have no idea really.

If a and b had a vendored c, you have an even more messy situation as security bugs exist in c1.1 and c1.5, but you don't even know which version you have if you pull in the ac and bc and compile against them, or if you can safely use two versions of c at once, your code uses c2.1 too, etc, etc.

Being explicit about versions is helpful for resolving dependency conflicts because it makes it explicit which version was expected at the time of writing, it doesn't magically solve all conflicts, no-one has this completely worked out, but it helps to be as explicit as possible when including other projects, and it is helpful in keeping up to date libraries whilst easily including them, even if you vendor.

If you have a large, open ecosystem of constantly evolving libraries, which I think golang should aspire to, it is useful to version them (just as golang itself is versioned).

Dependencies clashing is not always a binary thing. If they're well-specified, there may be a way to meet everything's version specifications.

Anyways, this isn't just academic. Tools to enable you to specify dependencies without vendoring them have been developed and used in several different environments, and at no point in using any of them have I gone "Gosh I wish I could go back to cluttering up my version control with other people's code!"

> If the dependencies clash, it doesn't matter what system you use. There isn't a package manager good enough to fix the issue of having conflicting dependencies.

With NPM, it's fine as long as the two modules aren't calling into each other with improper data as a result of the dependency clash (because each dependency is responsible for installing its own subdependencies, rather than relying on a global namespace/install location). So, you'd have a problem if A relies on C1, and B relies on C2, and you got data in format c1 in A and called into B which expected format c2. Otherwise, you're fine.