ChimeraCoder / anaconda

A Go client library for the Twitter 1.1 API
MIT License
1.14k stars 247 forks source link

Vendoring breaks build #230

Closed carbocation closed 6 years ago

carbocation commented 6 years ago

Maybe this is a problem on my end, but I use github.com/garyburd/go-oauth/oauth to construct credentials and I use anaconda.GetCredentials with these. Now that there is a version of oauth checked into Anaconda's vendor folder, I get the following error:

cannot use creds (type *"github.com/garyburd/go-oauth/oauth".Credentials) as type *"github.com/ChimeraCoder/anaconda/vendor/github.com/garyburd/go-oauth/oauth".Credentials in argument to anaconda.GetCredentials

If I delete the vendor folder from anaconda, it builds without issue. Is there something I need to be doing differently, or is this a real problem caused by the library having its own vendor folder?

ChimeraCoder commented 6 years ago

Alright, I've looked into this.

The short answer

I'm guessing this means you aren't using dep for vendoring. dep isn't required to use anaconda, but it's what anaconda itself uses to ensure reproducible builds. There are two ways you can solve this:

(1) Delete the vendor/ directory inside anaconda before building your project; or

(2) Use dep, which will solve this issue automatically.

The long answer

This basically has to do with how dep handles recursive vendoring differently from other vendoring tools. Dep will look at the Gopkg.toml files of all dependencies it finds (in this case, anaconda), and it'll incorporate that into its solver when determining which versions of recursive dependencies (e.g. go-oauth) to pull in. Other dependency management tools may not.

We could add the vendor directory to the .gitignore, because the Gopkg.{toml,lock} files are all that's needed to reconstruct the vendor directory; however, that would have two problems:

1) It would slow down CI times for anaconda, because it would need to pull in the packages over the network each time

2) If any of the upstream dependencies are deleted, anaconda will no longer be able to build at all.

(1) is a mere nuisance, but (2) is the real problem. We can't afford to have the entire library non-functional in case the author of one of our dependencies decides to delete their account (or has it taken suspended due to a DMCA request on a different repository they own, etc.).

Please let us know if either of the solutions I mentioned (delete the vendor directory/use dep) will work for you. I'm sorry for the inconvenience here - I don't like suggesting that you add an extra step to your builds if you want to use a tool other than dep, but it looks like that's the best answer. This (vendoring and reproducible builds for libraries) is currently a problem that's being actively discussed in the Go community at large, so that's where we are at the moment.

cc @sdboyer

ChimeraCoder commented 6 years ago

I'm going to close this because I believe either of those two solutions will work, but please let us know if that's not the case.