4 ms·
One thing I don't like is that sometimes when I reference a go library, sometimes it's vendored dependencies are exposed. This forces me to constantly keep my v
by pknopf 9y ago
One thing I don't like is that sometimes when I reference a go library, sometimes it's vendored dependencies are exposed. This forces me to constantly keep my vendor file in sync with theirs.
Is there something we can do about forcing a check to ensure things aren't out of sync? Maybe a module can define dependencies as internet/external? If a dependency is marked as external, the referencing library must reference that same exact dependency/library version?
- bbatha 9y agoVendoring is not supported by vgo so it’s not an issue
- pknopf 9y agoIf library authors can expose types of their dependencies, it still is an issue. Consumers must use the same exact version.
- bbatha 9y agoThat’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.
- y0ssar1an 9y agodep will ignore the library's vendor directory entirely. You don't need to do any of that work yourself. dep will do it for you. https://github.com/golang/dep https://github.com/golang/dep