Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go Modules: Better Way To Prevent Upgrading Customer Deps #810

Closed
felixge opened this issue Jan 11, 2021 · 7 comments
Closed

Go Modules: Better Way To Prevent Upgrading Customer Deps #810

felixge opened this issue Jan 11, 2021 · 7 comments
Labels
ack enhancement quick change/addition that does not need full team approval modules

Comments

@felixge
Copy link
Member

felixge commented Jan 11, 2021

Problem

The go.mod file in this repository currently contains only a single dependency despite the repository having many dependencies. @knusbaum told me this done because listing all of the dependencies with an explicit version could cause problems for customers which use lesser versions of these same dependencies in their application. The minimal version selection algorithm of Go modules would implicitly upgrade them to newer version which could break their code.

This idiosyncratic usage of Go modules has confused new contributors, including myself.

Proposal

For now I'll follow-up with a PR for the CONTRIBUTING.md file to mention this issue and to recommend using git update-index --assume-unchanged go.* as a workaround for local development to avoid accidentally committing modified go.mod/go.sum files.

Going forward we can also use this issue to discuss the problem in general and perhaps come up with a better solution.

@felixge felixge added enhancement quick change/addition that does not need full team approval modules labels Jan 11, 2021
@felixge
Copy link
Member Author

felixge commented Jan 11, 2021

cc @pmbauer @gbbr @knusbaum (just FYI, no action needed for now)

@felixge felixge changed the title Go Modules: Better Way to Prevent Upgrading Customer Libraries Go Modules: Better Way to Prevent Upgrading Customer Deps Jan 11, 2021
@felixge felixge changed the title Go Modules: Better Way to Prevent Upgrading Customer Deps Go Modules: Better Way To Prevent Upgrading Customer Deps Jan 11, 2021
@felixge
Copy link
Member Author

felixge commented Jan 11, 2021

PR for git workaround is ready: #811

@pellared
Copy link
Contributor

What do you think of splitting this repo into multiple Go Modules?
You can check how it is done in Go SDK for OpenTelemetry: https://github.com/open-telemetry/opentelemetry-go
I have also started doing some work on a fork signalfx/signalfx-go-tracing#67

@gbbr
Copy link
Contributor

gbbr commented Mar 22, 2021

@pellared we've considered it, but since it's very easy to make a mistake and screw everything up, we've avoided. If we find strong reasons to go that way, I am still open to it as a possibility. We should outline the advantages and disadvantages of that to properly take it into consideration.

@pellared
Copy link
Contributor

pellared commented Mar 22, 2021

@gbbr Might be worth checking how Google does it here: https://github.com/googleapis/google-cloud-go

@felixge
Copy link
Member Author

felixge commented Mar 22, 2021

@pellared thanks for the link. It seems like they have separate go.mod files for some, but not all, sub-directories. I'll dig into this some more later, but the approach seems worth considering.

@nsrip-dd
Copy link
Contributor

This is resolved by #1188 and by our policy of having minimum required versions for our contrib dependencies (https://github.com/DataDog/dd-trace-go/blob/main/CONTRIBUTING.md#go-modules).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ack enhancement quick change/addition that does not need full team approval modules
Projects
None yet
Development

No branches or pull requests

5 participants