A note about dependency types

[je...@drinktomi.com]

Any successful go package management solution needs to recognized some dependencies have different isolation requirements. Some dependencies are under a project's control, and some are not.

Ignoring this leads to solutions like vendoring. Vendoring attempts to compensate for lack of control through complete isolation from downstream changes, but it comes with comparatively high friction for incorporating changes, making vendoring a poor solution where packages are co-evolving together within the same organization. When dependencies are closely coordinated, and where interoperability issues are best resolved through social means (e.g. tapping someone one the shoulder, or having a meeting) then lighter weight mechanisms are beneficial.

Any packaging solution which intends to be useful for both open-source and large internal projects should be compatible with both sorts of dependencies.

[Dave Cheney]

Thank you for your email. Can you give some specific examples if a solution that did not use vendoring as a countet example?

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.