Add importer for govendor #815

kyleconroy · 2017-07-15T16:58:02Z

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 · 2017-07-15T16:59:07Z

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

rfay · 2017-07-15T17:44:26Z

To be determined:

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

kyleconroy · 2017-07-15T17:49:24Z

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

darkowlzz · 2017-07-15T18:02:36Z

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 · 2017-07-15T18:28:25Z

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 · 2017-07-15T18:28:29Z

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.

darkowlzz

Great work. 👍
Some initial feedback.

darkowlzz · 2017-07-15T18:17:09Z

cmd/dep/govendor_importer.go

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


Comment be ignored?

darkowlzz · 2017-07-15T18:23:45Z

cmd/dep/govendor_importer.go

+	Version      string
+	VersionExact string
+	ChecksumSHA1 string
+	Comment      string


I think we can ignore Comment, ChecksumSHA1 and RevisionTime?

darkowlzz · 2017-07-15T18:27:40Z

cmd/dep/govendor_importer.go

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


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.

darkowlzz · 2017-07-15T18:28:31Z

cmd/dep/govendor_importer.go

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


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

darkowlzz · 2017-07-15T18:40:21Z

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 · 2017-07-17T18:55:15Z

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

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!

carolynvs · 2017-07-18T21:02:39Z

cmd/dep/govendor_importer.go

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


Will Tree be used?

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

carolynvs · 2017-07-18T21:04:10Z

cmd/dep/govendor_importer.go

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


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

carolynvs · 2017-07-18T21:08:31Z

cmd/dep/govendor_importer.go

+		// 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)


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.

carolynvs · 2017-07-18T21:09:52Z

cmd/dep/govendor_importer.go

+				g.logger.Printf("Warning: Not able to convert ignoring of build tag '%v'", i)
+				continue
+			}
+			_, err := g.sm.DeduceProjectRoot(i)


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. 😊

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.

carolynvs · 2017-07-18T21:10:42Z

cmd/dep/govendor_importer.go

+			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)


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

carolynvs · 2017-07-18T21:13:32Z

cmd/dep/govendor_importer.go

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


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

carolynvs · 2017-07-18T21:17:28Z

cmd/dep/govendor_importer.go

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


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! 😀

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?

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.

carolynvs · 2017-07-18T21:22:20Z

cmd/dep/govendor_importer.go

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


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

carolynvs · 2017-07-18T21:26:24Z

cmd/dep/testdata/govendor/golden.txt

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


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

carolynvs · 2017-07-18T21:32:22Z

cmd/dep/testdata/harness_tests/init/govendor/case1/final/Gopkg.toml

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


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.

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.

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 · 2017-07-18T21:47:06Z

Poking to retry the CI builds..

carolynvs · 2017-07-18T22:06:34Z

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 · 2017-07-24T17:39:15Z

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! 😀

googlebot · 2017-07-29T06:01:29Z

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 · 2017-07-29T06:30:59Z

@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 · 2017-07-29T17:52:27Z

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

carolynvs

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.

carolynvs · 2017-08-07T17:00:11Z

cmd/dep/govendor_importer.go

+				ProjectRoot: pr,
+			}
+			if pkg.Origin != "" {
+				pi.Source = pkg.Origin


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.

carolynvs · 2017-08-07T17:05:01Z

cmd/dep/testdata/harness_tests/init/govendor/case1/final/Gopkg.toml

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


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.

darkowlzz · 2017-08-24T16:24:16Z

cmd/dep/govendor_importer.go

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


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

glasser · 2017-10-11T15:45:09Z

My govendor contained different revisions for different subprojects of golang.org/x/crypto...
Can you provide an example govendor config for me to look at? This is a valid concern but I think it's not limited to just govendor's import, so I may end up addressing it in a separate PR.

Yup, here you go: https://gist.github.com/glasser/4636916e87dbc89b8c949361dd116993

Take a look at golang/x/crypto specifically. I suspect this is something where govendor tries to use a consistent revision for projects but maybe only understands github.com...

(This vendor.json is from right after fixing the nested vendor/ issue; I can show you vendor.json with that issue if you'd like too.)

Still would have been nice if I could have figured out why grpc was used, though.
dep init builds up a graph of all your imported dependencies and the dependencies of your dependencies, regardless of if you had explicitly included in your govendor config. I'm guessing that while you may not directly import grpc, it is used by one of your other dependencies.

Ah yes, I mean, I understand at a high level why a project that I am not importing is being used, but I just mean that if dep init is giving me errors about a project I'd like to know specifically what parts of the graph it traced in order to discover it. After all, in this case I didn't actually need the library and it was only being brought in due to a bad choice of version for a different library.

(I hope these sorts of testing feedback are appropriate here! I really appreciate that you're implementing this!)

nicksrandall · 2017-10-12T14:23:52Z

I just want to say thanks for all this work!

fatih · 2017-10-25T07:22:02Z

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 · 2017-10-25T19:21:37Z

@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 · 2017-10-25T19:40:00Z

@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 (Support for private repositories e.g. Github Enterprise #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

Fallback to master automatically if the importer sees an empty revision. Not sure if this dep related or because of the govendor importer though
Try to simulate the imported on a publicly removed package. I think this needs to be fixed some how
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
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 Support for private repositories e.g. Github Enterprise #174. But would be helpful nevertheless if we can find a middle ground there.

carolynvs · 2017-10-26T01:47:12Z

@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.

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.

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 · 2017-10-30T08:05:42Z

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 · 2017-10-30T13:11:48Z

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 · 2017-11-09T23:23:06Z

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

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.

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 · 2017-11-11T17:39:11Z

@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 · 2017-11-11T17:45:51Z

@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. 💖 🙇‍♀️

ChrisHines · 2017-11-13T19:51:42Z

@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 · 2017-11-14T00:40:58Z

@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 · 2017-11-14T00:59:38Z

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

carolynvs · 2017-11-14T01:02:21Z

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

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

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.

Add vendor.json examples for govendor corner cases. Add first integration test case

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

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 · 2017-11-20T01:36:57Z

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

Works great! Thanks!

nezorflame · 2017-11-21T11:12:57Z

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! 👍 ❤️

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 · 2017-11-26T20:28:24Z

@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 · 2017-11-26T20:38:04Z

happily! 🎉🎉🎉🎉🎉

kyleconroy requested a review from carolynvs as a code owner July 15, 2017 16:58

googlebot added the cla: yes label Jul 15, 2017

kyleconroy mentioned this pull request Jul 15, 2017

GopherCon work on govendor importer kyleconroy/dep#2

Open

8 tasks

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

darkowlzz reviewed Jul 15, 2017

View reviewed changes

carolynvs suggested changes Jul 18, 2017

View reviewed changes

carolynvs closed this Jul 18, 2017

carolynvs reopened this Jul 18, 2017

kyleconroy force-pushed the govendor-importer branch from b610d81 to 7b13a3d Compare July 29, 2017 06:01

kyleconroy requested a review from sdboyer as a code owner July 29, 2017 06:01

kamilchm mentioned this pull request Aug 1, 2017

How to generate expressions for Hugo? kamilchm/go2nix#61

Open

carolynvs suggested changes Aug 7, 2017

View reviewed changes

carolynvs mentioned this pull request Aug 11, 2017

Alternate init modes #186

Closed

darkowlzz mentioned this pull request Aug 22, 2017

dep init failed to convert github.com/boz/kail from govendor to dep #1047

Closed

darkowlzz reviewed Aug 24, 2017

View reviewed changes

carolynvs force-pushed the govendor-importer branch 2 times, most recently from 4c3bdf0 to b9f1941 Compare November 11, 2017 18:38

kyleconroy and others added 5 commits November 14, 2017 21:42

internal/importers: add govendor importer

52b7df1

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

90a984d

Add vendor.json examples for govendor corner cases. Add first integration test case

internal/importers: add govendor importer

9033856

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

carolynvs force-pushed the govendor-importer branch from b9f1941 to 56cefc4 Compare November 26, 2017 18:11

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

kashav mentioned this pull request Jan 25, 2018

Missing release notes for v0.4.0 #1571

Closed

Add importer for govendor #815

Add importer for govendor #815

Conversation

kyleconroy commented Jul 15, 2017 • edited Loading

What does this do / why do we need it?

What should your reviewer look out for in this PR?

Do you need help or clarification on anything?

Which issue(s) does this PR fix?

kyleconroy commented Jul 15, 2017

rfay commented Jul 15, 2017 • edited Loading

kyleconroy commented Jul 15, 2017

darkowlzz commented Jul 15, 2017

kyleconroy commented Jul 15, 2017

googlebot commented Jul 15, 2017

darkowlzz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darkowlzz Jul 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darkowlzz commented Jul 15, 2017 • edited Loading

blainsmith commented Jul 17, 2017

carolynvs left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carolynvs commented Jul 18, 2017

carolynvs commented Jul 18, 2017

carolynvs commented Jul 24, 2017

googlebot commented Jul 29, 2017

kyleconroy commented Jul 29, 2017

carolynvs commented Jul 29, 2017

carolynvs left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

glasser commented Oct 11, 2017

nicksrandall commented Oct 12, 2017

fatih commented Oct 25, 2017

sdboyer commented Oct 25, 2017

fatih commented Oct 25, 2017 • edited Loading

carolynvs commented Oct 26, 2017 • edited Loading

fatih commented Oct 30, 2017

sdboyer commented Oct 30, 2017

rfay commented Nov 9, 2017

carolynvs commented Nov 11, 2017

carolynvs commented Nov 11, 2017 • edited Loading

ChrisHines commented Nov 13, 2017

carolynvs commented Nov 14, 2017 • edited Loading

ChrisHines commented Nov 14, 2017

carolynvs commented Nov 14, 2017

sjauld commented Nov 20, 2017

nezorflame commented Nov 21, 2017

carolynvs commented Nov 26, 2017

sdboyer commented Nov 26, 2017

kyleconroy commented Jul 15, 2017 •

edited

Loading

rfay commented Jul 15, 2017 •

edited

Loading

darkowlzz Jul 15, 2017 •

edited

Loading

darkowlzz commented Jul 15, 2017 •

edited

Loading

fatih commented Oct 25, 2017 •

edited

Loading

carolynvs commented Oct 26, 2017 •

edited

Loading

carolynvs commented Nov 11, 2017 •

edited

Loading

carolynvs commented Nov 14, 2017 •

edited

Loading