New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add importer for govendor #815

Merged
merged 6 commits into from Nov 26, 2017

Conversation

Projects
None yet
@kyleconroy
Copy link
Contributor

kyleconroy commented Jul 15, 2017

What does this do / why do we need it?

Adds support for importing dependencies from govendor-based projects.

What should your reviewer look out for in this PR?

There are now five mature importers. I'd like reviewers to make sure that this importer is consistent with the existing importers, as this code has been written over a few months. I'm worried that things might have changed internally.

Do you need help or clarification on anything?

@carolynvs has been helping with the PR, so I don't think I need any additional help.

Which issue(s) does this PR fix?

#1047

@kyleconroy kyleconroy requested a review from carolynvs as a code owner Jul 15, 2017

@googlebot googlebot added the cla: yes label Jul 15, 2017

@kyleconroy

This comment has been minimized.

Copy link
Contributor

kyleconroy commented Jul 15, 2017

We (@joeygoode, @rfay, @otoolec) started this work at GopherCon

@rfay

This comment has been minimized.

Copy link

rfay commented Jul 15, 2017

To be determined:

  • Should we collapse subpackages of the same imported repo, or should they remain separate, as govendor does it? (See #815 (comment))
@kyleconroy

This comment has been minimized.

Copy link
Contributor

kyleconroy commented Jul 15, 2017

Here is what the current output looks like: https://gist.github.com/kyleconroy/33016433c7d986065276bbc0467ceaa1

@kyleconroy kyleconroy referenced this pull request Jul 15, 2017

Open

GopherCon work on govendor importer #2

5 of 8 tasks complete
@darkowlzz

This comment has been minimized.

Copy link
Collaborator

darkowlzz commented Jul 15, 2017

Should we collapse subpackages of the same imported repo, or should they remain separate, as govendor does it?

@rfay yep, subpackages should be collapsed. Refer this in godep importer.

@kyleconroy

This comment has been minimized.

Copy link
Contributor

kyleconroy commented Jul 15, 2017

More questions: What should we do when a govendor package entry has an origin that points to a vendor directory in another project? The plan right now is to set the project identifier Source field to origin and hope that it works.

@googlebot

This comment has been minimized.

Copy link
Collaborator

googlebot commented Jul 15, 2017

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

@googlebot googlebot added cla: no and removed cla: yes labels Jul 15, 2017

@darkowlzz
Copy link
Collaborator

darkowlzz left a comment

Great work. 👍
Some initial feedback.

type govendorFile struct {
RootPath string // Import path of vendor folder

Comment string

This comment has been minimized.

@darkowlzz

darkowlzz Jul 15, 2017

Collaborator

Comment be ignored?

Version string
VersionExact string
ChecksumSHA1 string
Comment string

This comment has been minimized.

@darkowlzz

darkowlzz Jul 15, 2017

Collaborator

I think we can ignore Comment, ChecksumSHA1 and RevisionTime?

return nil, nil, err
}
manifest.Constraints[pc.Ident.ProjectRoot] = gps.ProjectProperties{
Source: pc.Ident.Source,

This comment has been minimized.

@darkowlzz

darkowlzz Jul 15, 2017

Collaborator

Source is specified when there's an alternate source of a project. So this can be removed from here and maybe added later when there's an alternate source found for a project.

Remove bool

// If new is set to true the package will be treated as a new package to the file.
Add bool

This comment has been minimized.

@darkowlzz

darkowlzz Jul 15, 2017

Collaborator

Are Remove and Add out of the usual govendor spec? Just curious how they would work 🙂

@darkowlzz

This comment has been minimized.

Copy link
Collaborator

darkowlzz commented Jul 15, 2017

More questions: What should we do when a govendor package entry has an origin that points to a vendor directory in another project? The plan right now is to set the project identifier Source field to origin and hope that it works.

@kyleconroy wow! people do that 😨
I'm not sure if that would work. You can give it a try and see if it works. Or you can handle such cases later, once normal cases work fine.

@carolynvs @ibrasho got any idea?

@blainsmith

This comment has been minimized.

Copy link

blainsmith commented Jul 17, 2017

I started this at the same time and just as I was about to issue a PR I saw this one since none existed 2 days ago at GopherCon. Haha!

@carolynvs
Copy link
Collaborator

carolynvs left a comment

I added a few questions/comments, and will do another review when all the tasks are completed and WIP is removed. Looking good so far!

// See the vendor spec for definitions.
Origin string
Path string
Tree bool

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

Will Tree be used?

This comment has been minimized.

@kyleconroy

kyleconroy Jul 29, 2017

Contributor

Right now it isn't. I'm going to remove it.

}

func (g *govendorImporter) load(projectDir string) error {
g.logger.Println("Detected govendor configuration files...")

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

Let's change this to "configuration file..." since there's only one.

// Dep doesn't support build tags right now: https://github.com/golang/dep/issues/120
for _, i := range strings.Split(g.file.Ignore, " ") {
if !strings.Contains(i, "/") {
g.logger.Printf("Warning: Not able to convert ignoring of build tag '%v'", i)

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

Since dep has future plans to support build tags, let's make it clear in this message and point them in the right direction.

Here's an example from the glideImporter:

The %s package specified an os, but that isn't supported by dep yet, and will be ignored. See https://github.com/golang/dep/issues/291.
g.logger.Printf("Warning: Not able to convert ignoring of build tag '%v'", i)
continue
}
_, err := g.sm.DeduceProjectRoot(i)

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

Can you help me understand why we are deducing the project root, then ignoring the result? I assume it has to do with partial paths or something, but it's not clear to me so maybe I'm wrong. 😊

This comment has been minimized.

@kyleconroy

kyleconroy Jul 29, 2017

Contributor

It was to do with case 3. It's very possible that this ignore directive is a package prefix, which isn't supported by dep. I'm updated the error message to make this obvious.

if err == nil {
manifest.Ignored = append(manifest.Ignored, i)
} else {
g.logger.Printf("Warning: Not able to convert ignoring of build tag '%v'\n", i)

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

Is this warning text correct? I thought the error was related to parsing the import path, and isn't related to build tags?

if pkg.Version == "" {
// When no version is specified try to get the corresponding version
pi := gps.ProjectIdentifier{
ProjectRoot: gps.ProjectRoot(pkg.Path),

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

I think that we already have the project root in pr from above, no?

This comment has been minimized.

@kyleconroy

kyleconroy Jul 29, 2017

Contributor

Yep!

ProjectRoot: gps.ProjectRoot(pkg.Path),
}
if pkg.Origin != "" {
pi.Source = pkg.Origin

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

source is the alternate location from which dep will download/clone/checkout the source code for the dependency, and if the origin looks something like "github.com/MSOpenTech/azure-sdk-for-go/vendor/crypto/tls" I doubt dep will know what to do with it.

I don't think this will work, but please let me know how it goes! 😀

This comment has been minimized.

@kyleconroy

kyleconroy Jul 29, 2017

Contributor

You're correct that it won't work for that case, but I don't think we have a way to determine which source values will work. If it fails, you can just update the vendor.json file to remove the source parameter. Do you have any other ideas on what we can do?

This comment has been minimized.

@carolynvs

carolynvs Jul 31, 2017

Collaborator

Since we know that any origin with a vendor segment is not going to work with dep, how about we check for those, and print a warning when we find an unsupported origin that it was ignored.

return
}

// buildLockedProject uses the package Rev and Comment to create lock project

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

Looks like this comment is left over from using godep as a starting point and should be deleted?

@@ -0,0 +1,7 @@
Detected govendor configuration files...
Converting from vendor.json...
Warning: Not able to convert ignoring of build tag 'test'

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

The warning should be indented with two spaces, so that it falls under the heading "Converting from vendor.json...".

ignored = ["github.com/sdboyer/dep-test"]

[[constraint]]
name = "github.com/carolynvs/go-dep-test"

This comment has been minimized.

@carolynvs

carolynvs Jul 18, 2017

Collaborator

This should have been ignored because it is only referenced by an ignored package samples, and should not have ended up in the manifest, lock or vendor.

This comment has been minimized.

@kyleconroy

kyleconroy Jul 29, 2017

Contributor

In the case1 vendor file, the ignore list contains three items, but only one is valid.

  • test isn't a package identifier, so it's skipped
  • github.com/sdboyer/dep-test is a valid package so it's added to the ignore list
  • samples/ is a package prefix, which isn't supported by dep, so we skip it

If samples/ was full path I think you'd be right. Please let me know if you think I've misunderstood the govendor ignore directive.

This comment has been minimized.

@carolynvs

carolynvs Jul 31, 2017

Collaborator

dep doesn't support wildcards yet, but we can at least try to preserve at least some of the intent behind ignoring a directory.

Glide supports something similar (excludeDir) and what the glideImporter does is join the project root of the project being importer (it's passed to Import) with the relative path to create a dep ignore entry. Here's the unit test. Would that work?

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Jul 18, 2017

Poking to retry the CI builds..

@carolynvs carolynvs closed this Jul 18, 2017

@carolynvs carolynvs reopened this Jul 18, 2017

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Jul 18, 2017

Let's also update the FAQ to add govendor to the list of supported tools.

https://github.com/golang/dep/blob/master/FAQ.md#what-external-tools-are-supported

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Jul 24, 2017

Let me know if you would like some help, or have questions.

Also, please ignore the failing PR builds, that is a problem on our end, not yours! 😀

@kyleconroy kyleconroy force-pushed the kyleconroy:govendor-importer branch from b610d81 to 7b13a3d Jul 29, 2017

@kyleconroy kyleconroy requested a review from sdboyer as a code owner Jul 29, 2017

@googlebot

This comment has been minimized.

Copy link
Collaborator

googlebot commented Jul 29, 2017

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@kyleconroy

This comment has been minimized.

Copy link
Contributor

kyleconroy commented Jul 29, 2017

@carolynvs I think I've addressed all your comments. What do you need me to do to get this over the line? I could use your help solving the CLA issue; I'm not sure what we need to do. Thanks!

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Jul 29, 2017

Don't worry about the CLA bot, that is a problem on our end, not yours.

@carolynvs
Copy link
Collaborator

carolynvs left a comment

  • The help text needs to be updated to list govendor as supported.
  • The FAQ needs to be updated to list govendor as supported.
  • I've readded some comments from last week that got lost in the shuffle.
ProjectRoot: pr,
}
if pkg.Origin != "" {
pi.Source = pkg.Origin

This comment has been minimized.

@carolynvs

carolynvs Aug 7, 2017

Collaborator

Since we know that any origin with a vendor segment is not going to work with dep, how about we check for those, and print a warning when we find an unsupported origin that it was ignored.

ignored = ["github.com/sdboyer/dep-test"]

[[constraint]]
name = "github.com/carolynvs/go-dep-test"

This comment has been minimized.

@carolynvs

carolynvs Aug 7, 2017

Collaborator

dep doesn't support wildcards yet, but we can at least try to preserve at least some of the intent behind ignoring a directory.

Glide supports something similar (excludeDir) and what the glideImporter does is join the project root of the project being importer (it's passed to Import) with the relative path to create a dep ignore entry. Here's the unit test.

func (g *govendorImporter) convert(pr gps.ProjectRoot) (*dep.Manifest, *dep.Lock, error) {
g.logger.Println("Converting from vendor.json...")

manifest := &dep.Manifest{

This comment has been minimized.

@darkowlzz

darkowlzz Aug 24, 2017

Collaborator

#1019 introduced Manifest Constructor. Let's use that here.

@fatih

This comment has been minimized.

Copy link
Member

fatih commented Oct 25, 2017

Just want to ask if this is ready to be merged? We're using govendor and I'm looking forward to test this out in our monorepo. Thanks

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Oct 25, 2017

@fatih i'd say that folks who're waiting for it could probably do us a solid by compiling dep from this branch and seeing how well it fares in converting their govendor cases, then reporting back. we're a bit gunshy about adding new importers, given the difficulty some folks have had with dep init in the past, but it's a bit of a catch-22 - it's hard to get testers to really put it through its paces until after we've merged, at which point we could be in an awkward spot where we're trying to put out a fire because we missed something that's occurring out in the wild.

@fatih

This comment has been minimized.

Copy link
Member

fatih commented Oct 25, 2017

@sdboyer definitely. I actually pulled this from this repo and run it on our monorepo at DO today!. We had a lot of problems, some which are known already to you, some were on our side. To list them:

  • The GHE problem is our biggest issue right now (#174). Just adding .git is not an easy workaround because we have hundreds of services that relies on these packages, so we need a big refactor just to make it workable.
  • We had a lot of packages with empty revision in our govendor.json. The importer complained about it and stopped working in this case. My workaround was changing the revisions in govendor.json from revision: "" to revision: "*". This would make dep fallback to latest master (not sure intentionally or not, but it worked)
  • There are packages in our monorepo, which seems like to be removed publicly. One of them being github.com/docker/distribution/digest. So because there is no revision history in govendor.json, it tries to fetch the latest, because there is no digest package anymore it fails to work. How to fix this? I'm not sure to be honest. On my side, I need to update all existing internal services to use a different package and remove digest entirely from our vendor folder. I've tried dep init -gopath but seems like this didn't worked out
  • There were some invalid entries in our govendor.json. One example would be github.com/miekg/dnsgithub.com() Don't ask how this end up in our govendor.json, but the importer just exited when it saw this. It was nice we detected it though.

My suggestions would be

  1. Fallback to master automatically if the importer sees an empty revision. Not sure if this dep related or because of the govendor importer though
  2. Try to simulate the imported on a publicly removed package. I think this needs to be fixed some how
  3. Just don't fail in the middle of the process. Our monorepo is hugeeee. It take 5-10 minutes just to try to read govendor.json and create the graph. Every single fail costs me tens of minutes. I think there is some caching dep is doing, but it's not enough
  4. Our biggest issue is yet the GHE issue. I'm not sure what I can say there as there are many other people who already talked this in #174. But would be helpful nevertheless if we can find a middle ground there.
@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Oct 26, 2017

@fatih Thank you for testing this out! 💖

We had a lot of packages with empty revision in our govendor.json. The importer complained about it and stopped working in this case.

Ooh, that's a misunderstanding of govendor's spec on our side and will get that fixed in this PR to not require a revision.

There are packages in our monorepo, which seems like to be removed publicly. One of them being github.com/docker/distribution/digest. So because there is no revision history in govendor.json, it tries to fetch the latest, because there is no digest package anymore it fails to work. How to fix this? I'm not sure to be honest. On my side, I need to update all existing internal services to use a different package and remove digest entirely from our vendor folder. I've tried dep init -gopath but seems like this didn't worked out

Correct me if I am misunderstanding but it sounds like the importer did not fail and dep init made it to the solve phase. From there, dep should have tried all of the repo tags in descending order, finally trying the tip of master. Sounds like none of those were suitable due to a removed package (and I'm guessing there were no tags to try). If you have the output from the init run, that would be helpful.

When you add the -gopath flag, dep will first take the imported metadata from the importer and combine it with what it finds in the gopath. The imported metadata takes precedence and the gopath is only used when the importer found no information for a dependency. Again output would be helpful if you have it as I'm not sure where the bad package is being introduced.

  1. Try to simulate the imported on a publicly removed package. I think this needs to be fixed some how

I do not understand what you are suggesting?

There were some invalid entries in our govendor.json. One example would be github.com/miekg/dnsgithub.com() Don't ask how this end up in our govendor.json, but the importer just exited when it saw this. It was nice we detected it though.

In order for us to use the importers during dep ensure, not just dep init, our importers need to start being more flexible about bad data. Printing warnings and doing their best, instead of hard failing. Which is a part of the same issue below. I've opened #1315 to capture this requirement.

  1. Just don't fail in the middle of the process.

We have an open issue for this #909 and a PR #1280. Agreed, losing all that time is incredibly frustrating.

@fatih

This comment has been minimized.

Copy link
Member

fatih commented Oct 30, 2017

Thanks @carolynvs.

Sorry for my poor explanation on this. For my second point, I was trying to say we should test the case when a publicly available package is not available anymore.

I've fixed some of our issues for govendor.json, but point 4 (GHE) is a blocker right now. I'm following the issue #174 and hope we can have a middle ground we can use for our monorepo as well.

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Oct 30, 2017

I've fixed some of our issues for govendor.json, but point 4 (GHE) is a blocker right now. I'm following the issue #174 and hope we can have a middle ground we can use for our monorepo as well.

this is the kind of thing that sufficiently large clients of github could probably get together and pressure them to fix the go-get metadata implementation in GHE. hint hint 😉

@rfay

This comment has been minimized.

Copy link

rfay commented Nov 9, 2017

I took this PR for a spin with two of our repos that had nontrivial vendor directories built with govendor.

  1. ddev@22498e2eeb:
  • There was one element in the vendor.json with no revision, and dep choked and refused to continue. I put a reasonable revision in there and all worked out fine.
  • dep found and supported vendor items (semver and google/go-github) which were in vendor directory but weren't in vendor.json. (And it changed the version on them, I don't know how it would have had any choice, it had no way to determine the initial version)
  • Some places (docker/docker) where subpackages were previously imported in govendor the full package is now downloaded, so there are extra files like READMEs and such that weren't previously there. It seems to me like this is by design, as govendor does subpackage-by-subpackage and dep gets the root of the vendored repo.
  1. crd-app-controller had some really interesting behavior.
  • Lots of output like Ignoring imported source k8s.io/apimachinery/vendor/github.com/PuerkitoBio/purell for github.com/PuerkitoBio/purell because vendored sources aren't supported. These seem to be a result of "Origin" fields that govendor uses, as in:
                {
                        "checksumSHA1": "9Ob5JNGzi/pGXYMuHclig69IHPk=",
                        "origin": "k8s.io/apimachinery/vendor/github.com/PuerkitoBio/purell",
                        "path": "github.com/PuerkitoBio/purell",
                        "revision": "6134cb2da6d90597b0434e349f90f94fafc9ae51",
                        "revisionTime": "2017-07-19T03:38:15Z"
                },

I'm pretty sure that dep should be completely ignoring the "origin" field on import, as it's irrelevant as I understand things. The idea of origin (unless I'm mistaken) is just to point to some upstream repo from the "path" repo.

Anyway, I did modest comparisons of the end result on both of these govendor-based repositories, and they worked out pretty well. Thanks for all the great work on this!

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Nov 11, 2017

@fatih

For my second point, I was trying to say we should test the case when a publicly available package is not available anymore.

That is a dep-wide concern, so let's do it outside of this govendor import PR. If we need dep to handle that case differently, and it sounds like there is room for improvement 😀, would you want to open an issue and lay out what you think should be changed?

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Nov 11, 2017

@rfay

Some places (docker/docker) where subpackages were previously imported in govendor the full package is now downloaded, so there are extra files like READMEs and such that weren't previously there

Yup, that is expected behavior when switching to dep because as you noted, dep vendors the root of the containing repo, not just a sub-package. You can run dep prune (which is soon to be moved directly into dep ensure in the next release) to remove unused packages and cleanup the root of the repo if nothing is used from the root (that root behavior is in the next release IIRC).

I'm pretty sure that dep should be completely ignoring the "origin" field on import, as it's irrelevant as I understand things. The idea of origin (unless I'm mistaken) is just to point to some upstream repo from the "path" repo.

I thought that origin could be used to figure out if an alternate source for the project should be used, such as using a fork or private repo? I'd hate to ignore origin entirely if there's a chance that it will cause necessary import metadata to be missed. But maybe we should move printing those warnings into the verbose mode?

I did modest comparisons of the end result on both of these govendor-based repositories, and they worked out pretty well. Thanks for all the great work on this!

Yay! Thank you for the feedback and kicking the tires. 💖 🙇‍♀️

@carolynvs carolynvs force-pushed the kyleconroy:govendor-importer branch 2 times, most recently from 4c3bdf0 to b9f1941 Nov 11, 2017

@ChrisHines

This comment has been minimized.

Copy link
Contributor

ChrisHines commented Nov 13, 2017

@glasser reported above:

Immediately after running dep init, I tried to run dep prune and was told that the lock was out of sync. I re-ran dep ensure and it changed the inputs-digest (and nothing else). Is that a bug in this PR?

The same thing happened to me just now.

As someone used to govendor's behavior, not having #944 and #1113 feels painful.

Otherwise, so far, so good. I was able to import a govendor spec for a medium sized project with some pinned deps (including k8s.io/client-go at v2.0.0-alpha.1) and it built and tests passed.

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Nov 14, 2017

@ChrisHines Are you able to link me to the repo that you migrated using this govendor importer that immediately resulted in an out of sync lock? I thought I had fixed that earlier but looks like it's still a problem.

@ChrisHines

This comment has been minimized.

Copy link
Contributor

ChrisHines commented Nov 14, 2017

@carolynvs Alas, the repo is private and I cannot share it.

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Nov 14, 2017

No worries. I'll keep this in the back of my head and see if I can figure out what's changing.

kyleconroy and others added some commits Jul 15, 2017

internal/importers: add govendor importer
Add skeleton for govendor importer

Parse the vendor.json file

Contemplate version when generating Gopkg.toml

Add ignored packages from vendor file

Remove unnecessary vendor file fields
internal/importers: add govendor importer
Add sample vendor.json for writing tests

Add skeleton test file for Govendor

Initial stab at generating lock from govendor

Get our first test passing

Fixes some bad porting of code from godeps implementation.
Removes some ported code from glide implementation.

Update govendor ignore logic for full package names

Add warnings for unhandled ignore

Update feedback to support revision without version

Doing this so we can get feedback for the detached head
use case that govendor frequently has.
internal/importers: add govendor importer
Add vendor.json examples for govendor corner cases.

Add first integration test case
internal/importers: add govendor importer
Translate glide unit tests to govendor

Include revision in test govendorFiles

Add a test for ignored packages

Don't expect ignored directories to actually be ignored

Use printf for formatting directives
internal/importers: add govendor importer
Add an `Any` constraint for projects

Standardize warnings around ignored build tags

Also make few minor changes to logging messages.

Add govendor to the list of supported tools

Sort the list of organized tools alphabetically as well.

Use manifest constructor function
@sjauld

This comment has been minimized.

Copy link

sjauld commented Nov 20, 2017

Tested this today when building https://github.com/terraform-providers/terraform-provider-aws

Works great! Thanks!

@nezorflame

This comment has been minimized.

Copy link

nezorflame commented Nov 21, 2017

Wanted to chime in with another approval of a successful usage for the https://github.com/TykTechnologies/tyk repo.
Moved from govendor to dep with no issues whatsoever.
Good work everyone! 👍 ❤️

internal/importers: add govendor importer
Move govendor files into importers pkg

Expose the base importer's source manager
It is used by the govendor importer to detect ignored packaegs

Update govendor importer to use base importer

Document exported members

Remove unused testdata

Import ignores with wildcards

Add govendor support to changelog

Do not import vendored sources

Don't require a revision to import govendor config
There are valid govendor configs in the wild that do not have a revision
set, essentially requiring the package but not locking to a revision. We
should allow that and not stop the import.

@carolynvs carolynvs force-pushed the kyleconroy:govendor-importer branch from b9f1941 to 56cefc4 Nov 26, 2017

@carolynvs

This comment has been minimized.

Copy link
Collaborator

carolynvs commented Nov 26, 2017

@sdboyer Would you please merge this for me? I can't because of the cla check (everyone has signed).

I have squashed all the commits from the authors (@kyleconroy, @otoolec, @joey-clypd and @brendan-munro) into a couple commits that preserve the original authors, incorporated feedback from the PR, and addressed merge conflicts with master.

@sdboyer sdboyer merged commit 7ccbfed into golang:master Nov 26, 2017

3 checks passed

codeclimate All good!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Nov 26, 2017

happily! 🎉🎉🎉🎉🎉

@davegaeddert davegaeddert referenced this pull request Nov 26, 2017

Open

Go support #4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment