DataDog
Mitigate go module issues using build tags
This patch adds build tags and information in CONTRIBUTING.md to reduce the pain for contributors until we can find a better solution to #911.
I don't consider this a long term fix, but this is probably better than nothing until we can come up with a better solution.
edit: added a picture below that shows the default experience VS Code users will have in Go 1.16 without solving this issue:
@gbbr @knusbaum this is just an idea for making the local dev experience better until we have a proper solution to the issue. The reason I'm submitting this is because I find myself constantly fighting my local tooling/editor complaining about these two packages, so it would help me a lot : ).
Anyway, it's just an idea. PTAL and let me know what you think.
Running go get gopkg.in/DataDog/dd-trace-go.v1/... should cause an error. We're asking it to recursively download the entire tracer, and all contrib dependencies. Since there are dependency conflicts, this can't succeed.
I think we shouldn't add a hack to cover this error up, but rather instruct our users not to use go get gopkg.in/DataDog/dd-trace-go.v1/.... They don't need to pull every dependency for every contrib package anyway. go get/build/test are generally smart enough now to pull in what's needed when it's needed.
@felixge, Is it feasible to configure in your editor not to pull all the packages, or is this something that will continue to be a problem?
@felixge, Is it feasible to configure in your editor not to pull all the packages, or is this something that will continue to be a problem?
Well, my editor NeoVIM with Coc/vim-go (as well as any other Go editor) relies on a collection of dozens of go tools to provide various features. I think it's reasonable to assume that some of them will at various points attempt to check the referential integrity of any package in the current go module. Arguably build tags are the best shot at consistently appeasing these tools. Otherwise I don't see a good way to ensure consistent configuration for something like this, especially if we want to support a wide range of editors and tools used by potential contributors.
Based on the above, I think our goal should be to have go build ./... complete without errors or warnings in the root of this module. This PR is one way to accomplish this, but I'd be totally open to other approaches as well.
Does this goal make sense to you?
@felixge I'm going to close this. I think we're past this since we have a proper go.mod now.
Please re-open if I'm mistaken.