On Saturday, July 28, 2018 at 11:43:04 AM UTC-7, nafis wrote: > > Suppose I'm making a library and it does reference some other library not > part of the standard library. I want to vendor those so that my library > doesn't fail if the other 3rd party developer deletes their library or > major changes of their library(I know this sound like stupid design). And I > want to push the vendor folder on my library repo. My question: Is this > the bad idea keep a vendor folder on the library repo. > > Thank you for your time. >
There are some practical considerations to vendoring within a library: 1. If any types from a vendored package appear in the exported interface of your library, no caller will be able to write down the full names of those types because their imports are not from your vendored package path, and so your library may be difficult to use. 2. If the package you are vendoring does anything that relies on the full resolved package path at runtime -- for example, gob encoding uses it by default via reflection when registering types -- then the copy in your vendor directory will see the vendor package path, which may cause problems if the resulting value leaves your program and must be consumed by another program that was expecting the "canonical" path. I believe if neither of these are true for your library then the decision is entirely internal to your library and callers will not be able to observe any difference compared to a non-vendored copy of the same dependency. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
