godebug stub to fix build error with Go 1.21 #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Upstream interface to internal/godebug has changed, so the sed replace from PR#3 is no longer matching nor is suffcient in Go 1.21. Build fails with errors on lines with godebug references.
Suggesting a different approach: substitute godebug with a stub. Hopefully it's more robust than hacking more sed replace expression to cover every line. Still might go out of date if upstream changes the interface again, but updating the stub to match the updated interface should be more straightforward than with sed expressions.
Since godebug is accessed via
godebug.Foo()
, godebug stub needs to be an actual module with its own path. Imports via a relative paths are not allowed in "module mode". True? Or is there a trick to somehow make this godebug stub a "local" module?The downside of the stub being a module is that now one extra module path needs to be replaced with 'go mod edit' to point to the local directory. And, unfortunately, it is not sufficient to do it only in the dependency module; it needs also needs to be done for the parent application.
Also, for build on Go <1.17 without Go modules, I didn't try it, but presumably no separate command is needed, assuming go get is smart enough to find the nested godebug stub, just like it finds the other local dependencies modules. Not sure.