Fix: goa gen ignores vendor directory

[davepgreene]

This PR fixes #2978 by only running go get from generator code if the module does not have a vendor directory. The gotcha is that the vendor directory must contain the goa.design/goa/v3/codegen/generator.

Because of the general guarantee that using a vendor directory provides a measure of predictability in builds, I'm reluctant to find some way to install that package as part of the code generation process. Instead, it may be more appropriate to document this requirement and suggest the user use the tools.go model to ensure the package is included.

I'm open to suggestions for how to handle this case.

[raphael]

This looks great, thank you. Make sense that the goa tool wouldn't automatically update the vendor directory. Could it check whether it's there and print a nice error message explaining that it needs to be?

[davepgreene]

I like that idea and have some ideas as to how I might implement it. I'll update this PR when I get a chance.

[davepgreene]

Back to the drawing board. There's no consistency between what the packages package and go list reports in terms of identified, vendored dependencies. Might have to parse the vendor/modules.txt or go.sum to actually determine whether the goa.design/goa/v3/codegen/generator package is actually stored on-disk.

[raphael]

Could it do something as simple as whether the goa sub-directory exist?

[davepgreene]

Could it do something as simple as whether the goa sub-directory exist?

I was hoping for something more elegant than that but the vendor directory has a known enough structure to be able to walk it.

The other thing is that the presence of the directory doesn't necessarily indicate the completeness of the package contained within.

Another approach that might be awful but would certainly give us enough info would be to create another temp dir, write a go file with a bare import of the relevant package and attempt to build it, capturing errors with enough info to make it actionable.

Alternatively we could test the output of the go build command that is called from Compile and if it matches the error we expect for not having the vendored dependencies, surface it in an actionable way for the user.

[raphael]

Yeah it's not the most elegant for sure, an alternative could be to add a error handler (instead of checking proactively) that would understand that vendoring is enabled and suggest making sure that Goa is vendored. It depends a bit on how easy or hard it is to write such a handler...

[davepgreene]

Unfortunately the biggest issue at hand is just that the go command understand vendor context but the code it relies on is deep in internal packages. We're forced to either be proactive in testing whether the go build command works or be reactive in testing the output from the compiler.

[davepgreene]

@raphael is there a good location to document troubleshooting information? I noticed the docs aren't in the docs directory and, beyond that, I don't see a good place to point users to in order to describe what might be going wrong either in the README or at https://goa.design.

[raphael]

The closest that exists to this atm is the FAQ https://goa.design/learn/faq/ - but happy to create an explicit troubleshooting document if that makes more sense.

[davepgreene]

I've updated with the best approach I could come up with. Instead of trying to determine if the dependency is satisfied ahead of time, we just check the error that comes from go build (which will happen every time we try to generate without the goa.design/goa/v3/codegen/generator package available) and if we have a vendor directory, surface the error to direct the user to the troubleshooting section of the README I added.

[raphael]

Looks great, thank you!