chore: remove fmt.Errorf across the codebase in preference of errors.Errorf/Wrap#3305
chore: remove fmt.Errorf across the codebase in preference of errors.Errorf/Wrap#3305tonistiigi merged 6 commits intomoby:masterfrom
Conversation
bff9252 to
1361f2f
Compare
Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
Signed-off-by: Justin Chadwell <me@jedevc.com>
1361f2f to
751a2c1
Compare
|
The upstream https://github.com/pkg/errors is archived, can we fork it? |
That has come up a few times. I know we still have an interest in using that package over Go's standard wrapping (as we use information we use when crossing boundaries, see containerd/containerd#6937 / containerd/containerd#6937 (comment)). I know we discussed at some point to see if some of us can take over maintainership of In general, the package is basically "feature complete", so I don't expect much maintenance (and we definitely shouldn't change the scope of the package), but I see people get nervous because it's archived. @davecheney would you be open to discuss options? |
In general, we prefer to use
github.com/pkg/errorswherever possible, since it provides stacktraces, and we try and enforce this in code-review. However, this is easy to forget (especially for me 😄) - so we should provide a linting rule to ban usingfmt.Errorf. This should stop these leaking through in future PRs.This PR adds a linter rule to
forbidigo, to ban this function, requesting that users switch to using theerrorspackage. As part of this, we also need to update all the instances offmt.Errorf, which was useful to cleanup some cases of code-rot.