Keep Vendor folder on library Repository is Bad or Good practice.

322 views
Skip to first unread message

nafis

unread,
Jul 28, 2018, 2:43:04 PM7/28/18
to golang-nuts
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.

Miguel Angel Rivera Notararigo

unread,
Jul 28, 2018, 8:44:28 PM7/28/18
to mirzanaf...@gmail.com, golan...@googlegroups.com
IMO it is not a bad idea or a stupid design if that is the best approach for your project. Having just the for loop sounds crazy for many developers, but we love that 😂

Mirza Nafis Faysal

unread,
Jul 28, 2018, 8:46:02 PM7/28/18
to Miguel Angel Rivera Notararigo, golan...@googlegroups.com
Haha, thanks! 

nafis

unread,
Jul 28, 2018, 8:47:40 PM7/28/18
to golang-nuts
Ha ha thanks, but I saw some of the developers seriously gona mad if I keep the vendor folder on my library.

Miguel Angel Rivera Notararigo

unread,
Jul 28, 2018, 10:36:28 PM7/28/18
to Mirza Nafis Faysal, golan...@googlegroups.com
See this projects https://github.com/dgraph-io/dgraph https://github.com/docker/cli, I am sure that some super Software Engineers work in these projects and they don't think that having the vendor folder in the repository is a bad idea. Sometimes pushing the vendor folder is the best approach, sometimes not, pick the one that better fits to your project 😁

T L

unread,
Jul 30, 2018, 12:10:00 PM7/30/18
to golang-nuts
I prefer keep vendor folder. The reason is some external libraries may disappear later.
However, I don't know how well vgo supports vendor folders in project directory outside of GOPATH.

Eric Johnson

unread,
Jul 30, 2018, 7:49:36 PM7/30/18
to golang-nuts
Long term, I suspect you're better off without the vendoring.

Specifically, I suggest looking into automating your libraries tests with the earliest possible versions of supported dependencies, and the latest versions of dependencies.

With a tool like vgo, it should be possible to have two versions of your lock file that your build / test cycle can switch between. If a project adds backwards compatible changes, they you can test across major versions as well.

Eric
Message has been deleted
Message has been deleted

nafis

unread,
Aug 1, 2018, 9:50:13 AM8/1/18
to golang-nuts
How about the Author delete the library.

Tong Sun

unread,
Aug 8, 2018, 10:01:32 AM8/8/18
to golang-nuts
I've never seen that happen before, but in case it does, only new environments will fail, i.e., those has been building fine will still be building fine. I.e. it's quite easy to correct. 

So I personally think that it is really a high price to pay for something that may never happen. 
Of course, not everyone agree with me, as I've seen someone even worries that go yaml (gopkg.in/yaml.v2) will go away someday, and insists vendering it. 

Manlio Perillo

unread,
Aug 8, 2018, 10:14:31 AM8/8/18
to golang-nuts

Tong Sun

unread,
Aug 8, 2018, 10:27:22 AM8/8/18
to golang-nuts
IMHO, the npm node packaging is just a mess -- I have several similar projects, and each has to pull in a HUGE pile of almost-identical dependencies, and not able to reuse between them at all. Whatever happening over there will not astonish me at all, including the infamous npm_left_pad_chaos problem. 

Go packaging is far super than npm -- chaos at npm does not imply Go will suffer the same. 

On Wednesday, August 8, 2018 at 10:14:31 AM UTC-4, Manlio Perillo wrote:

peterGo

unread,
Aug 9, 2018, 8:58:16 AM8/9/18
to golang-nuts
Tong Sun

"I've never seen [the Author delete the library]  happen before."

It happened recently. Take a look at jteeuwen/go-bindata: Hard fork of jteeuwen/go-bindata because it disappeared,

Peter

Tong Sun

unread,
Aug 13, 2018, 11:18:30 AM8/13/18
to golang-nuts
I have no idea what's going on there or the history, but I see https://github.com/jteeuwen/go-bindata is still there, despite that "this repository is not maintained".

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/yASFt3PY_yg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jfbus...@objenious.com

unread,
Aug 13, 2018, 12:08:33 PM8/13/18
to golang-nuts
IMHO

Don't do it for a library. Let your users decide if they prefer to commit their vendor directory or not.

Do whatever you want for a standalone project.

JFB

Dan Kortschak

unread,
Aug 13, 2018, 9:25:43 PM8/13/18
to Tong Sun, golang-nuts
It is still there because someone if (hopefully) benificently name
squatting there with the same package. It went away and broke things.
The person who owns jteeuwen is not Jim (the original owner), and has
put back the go-bindata repo to avoid a breakage. It could be far
worse.

ma...@degeneration.co.uk

unread,
Aug 13, 2018, 9:26:33 PM8/13/18
to golang-nuts

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.


Reply all
Reply to author
Forward
0 new messages