Vendor everything regardless of build tags

[freeformz]

Currently we end up respecting build tags when we select files/packages for vendoring. This causes problems when vendoring happened on a target platform that isn't the one you are building on. We should ignore build tags when selecting files.

[captncraig]

I have an app that we build for multiple os/arch combinations. godep is not working for me because it only includes files for the current build tags, and deletes previous ones from other build tags. I would like to switch to godep, but it is difficult if this is not resolved.

[captncraig]

It looks like this will be difficult to do with the current implementation that executes go list, as that has no option to ignore tags. It should be feasible by invoking go/build things directly. I may make an attempt in that direction.

[captncraig]

On second thought, it may be difficult to do with go/build too. You can import a package using UseAllFiles, which will ignore all tags, but in my testing that tends to expose a lot of errors with packages that have a secondary main package with // +build ignore, or things like that.

build.Package does expose AllTags which tells you which tags are relevant in any way. You could potentially use that to call Import multiple times, but it is tricky to know which values are for GOOS, which are for GOOARCH, and which are to be given as raw tags. Not to mention things like ignore or race should be special cased. Build constraints on a file may always be in an odd combination like // +build !linux,amd64 darwin,!386 in which case I don't have a clue what to do. go/build is also not recursive, so that would need to be done manually as well.

The real problem I have is that running GOOS=windows godep save deletes packages not needed for the windows build. If I then run GOOS=linux godep save, it will add linux dependencies, but delete the windows ones. Perhaps this behavior could be disabled by a flag and print a warning or something like that so I can manually prune things if needed. That may be a simpler solution.

Alternatively, we could do go list 3 times with GOOS=windows linux and darwin, and then merge the deps. A bit of a halfway hack, but it may cover 90% of what causes trouble for people in this situation.

[darkliquid]

I get bitten by this issue a lot as well. One thing I've been toying with (but have yet to actually write) is a script to that will take a list of GOARCH and GOOS that your project supports, then run godep against every combination, at each step unstaging any deletions and adding any new packages (assuming git). It a right pain in a backside to have to do this though - it'd be nice if go list had some kind of 'ignore all tags' option that would make it list everything all the time (maybe my passing in * to the -tags argument). Until then, manual hacks and workarounds seem to be the only way forward.

[freeformz]

@captncraig Yep. I've spent a lot of time going down that same path and before I went on vacation (which I'm back from) I started writing my own version of go/build.Context because of this. It's no where near ready though. ;-)

[chancez]

This is a huge problem I've ran into on multiple occasions. Thankfully CI catches it, but it makes working with dependencies really difficult.

[hqhq]

It's really pain for godep, hope we can get progress ASAP?

[freeformz]

FWIW: I'm acutely aware of this issue every day.

[gyuho]

+1. Any updates on this?