Support https://github.com/kardianos/vendor-spec

[freeformz]

We should do so, or at least understand why we can't.

[freeformz]

FWIW: I am slowly working through the godep code to understand it's idiosyncrasies better than I do now and with an eye towards this. No promises and if anyone surprised me with a patch that would close this issue I wouldn't complain. ;-)

[mattfarina]

I found the vendor-spec project to not meet my needs for Glide so I started to work on https://github.com/mattfarina/pkg. It's a little different in scope. Even if Godep doesn't use it or either of them I'd be curious why.

[freeformz]

@mattfarina What needs did you feel were not met?

[mattfarina]

@freeformz I think this has to do with a difference in the way we do things. I come from a background using npm, Composer, bundler, and package managers in other languages. When I think of populating the dependencies I think of populating the vendor/ folder with the appropriate needs (assuming the Go 1.5 vendor experiment style).

The vendor-spec, as I learned through conversations in the issue queues, is ideally for a workflow where you have a package in your $GOPATH and you want to copy it to the vendor/ directory. It captures the information for that quite well.

Here are a couple cases I don't see being met:

• When I have a private repo (package) and want to update it in the vendor/ folder. The Origin in the vendor-spec gives the original path but doesn't contain enough information to fetch it from a location like git@github.com/foo/bar. Instead it's assumed you maintain that private package in your $GOPATH and your copying it to the vendor/ folder.
• You need to flatten the dependency tree. For example, you have multiple packages that vendor a database driver. If the same driver is in more than one location you get issues with your vendor/ folders. Sometimes you need to flatten it out so there is just a single location for the driver. We already had to implement this fix in Glide.

I'm curious what you think and what workflow you see being useful for people.

[kardianos]

@mattfarina Hi Matt, not to argue, but I would like to point out that;

• govendor, which uses the vendor-spec has remote updates on the radar https://github.com/kardianos/govendor/issues/44 . Just hasn't been my top priority to implement.
• govendor, which uses the vendor-spec, has always flattened the dependency tree.