4 ms·
That’s untrue. You will only be able import the library once and that version will be common across your all of your dependencies. Only major version breaks cha
by bbatha 9y ago
That’s untrue. You will only be able import the library once and that version will be common across your all of your dependencies. Only major version breaks change this equation, but as explained in the third article those imports will have different names and are effectively different libraries.
- deleted 9y ago[deleted]
- pknopf 9y agoHmm, can I reference multiple versions of the same library? Not that I'd want to, just wondering how it works.
- Skinney 9y agoOnly different major versions (that is, you can reference a/v1 and a/v2 in the same project, because the import path is different).
- bbatha 9y agovgo will guarantee that you only receive a single resolved minor version for any given major of a package. Each major will be imported as a different name, e.g. `import “registry.io/my/pkg”` for v1, `import “registry.io/my/pkg/v2”, etc. Because vendoring is disallowed by vgo that means that you don’t need to worry about issues like `import “registry.io/pkg”` conflicting with `import “yourlib/vendor/registry.io/pkg”`.
- stubish 9y agoMajor versions of the same library are available, referenced by different paths. It works if they don't reference any global resources outside of their own package. If they do reference any global resources (such as the using the standard flag package, paths on the filesystem, mutexes etc.), then things can fail badly. Yes, this means if one of your dependencies pulls in a different major version of a package than used by other dependencies, then they can end up duelling over resources.