Switch from pkg/errors to Go 1.13+ error wrapping

[kolyshkin]

Fixes: #1614

The github.com/pkg/errors is mostly obsoleted since Go 1.13 introduced
%w-style error wrapping. It is also not maintained and is now archived
by the owner.

Some part of this change was done manually, and some changes were done
by using https://github.com/AkihiroSuda/go-wrap-to-percent-w tool.

In a few places this also:

• changes '%s' or "%s" to %q;
• removes extra context from the error message (such as, errors from os
  functions dealing with files do contain the file name already, and
  strconv.Atoi errors already contains the string which it failed to
  parse).

Note that there is a single place which uses StackTrace functionality of
pkg/errors, which is removed by this PR.

A few remaining users of pkg/errors vendored here (directly and
indirectly) are:

• github.com/containerd/go-runc (needs to be bumped to v1.1.0);
• github.com/microsoft/didx509go (needs deps: update to github.com/lestrrat-go/jwx/v2 didx509go#19);
• github.com/docker/cli (needs Consider dropping dependency on github.com/pkg/errors docker/cli#3618 fixed);
• github.com/docker/docker (?)
• github.com/linuxkit/virtsock (needs Switch from pkg/errors to %w style wrapping linuxkit/virtsock#69 merged);

[kolyshkin]

Is this repo maintained?

[kolyshkin]

@kevpar @anmaxvl @katiewasnothere PTAL

[kolyshkin]

Some of linter errors are pre-existing and some are new. I can fix them all (either here or in a separate PR) if there's enough interest.

[anmaxvl]

@kolyshkin, thanks for the PR. We need to figure out what we want to do with StackTrace, since it'll be a breaking change for our LCOW (Linux containers on Windows) scenario.

[kolyshkin]

@kolyshkin, thanks for the PR. We need to figure out what we want to do with StackTrace, since it'll be a breaking change for our LCOW (Linux containers on Windows) scenario.

@anmaxvl if the code is open source, can you please link to it? (so we can assess how this breaking change can be handled)

[jiechen0826]

Hi @kolyshkin, thank you for opening the PR.

We would like to keep using the stack trace capability that comes with the github.com/pkg/errors. As you can see there are many calls to errors.Wrap and errors.Wrapf in the codebase, we can't replace all of them with the native go error.

This may not be a unique issue to us, do you know if there is any good alternative to be used here?

If not, we will need to consider creating a custom error type to wrap around the native go error and add back the stack trace functionality.

[kolyshkin]

Hi @kolyshkin, thank you for opening the PR.

We would like to keep using the stack trace capability that comes with the github.com/pkg/errors.

Realistically, do you need a stack trace for every error? Taking into account that

• stack traces are rarely needed
• stack traces are expensive to get

they should not be used in most cases. And when you do want a stack trace in an error, it should probably be added explicitly.

As you can see there are many calls to errors.Wrap and errors.Wrapf in the codebase, we can't replace all of them with the native go error.

Historically, Go standard libraries did not have features that third-party packages like github.com/pkg/errors provide, like wrapping the error, this is why lot of software uses those errors.Wrap etc.

This has changed with Go 1.13 (see https://go.dev/blog/go1.13-errors and the Go issue linked from there). Later, Go 1.20 added wrapping of multiple errors.

So yes, now you actually can replace errors.Wrap[f] with %w (as this is done by this PR). the only feature you lose is stack traces.

This may not be a unique issue to us, do you know if there is any good alternative to be used here?

If not, we will need to consider creating a custom error type to wrap around the native go error and add back the stack trace functionality.

Lot of software switched to standard Go error wrapping (and lost stack trace on error functionality).

I think you can consider the following options:

• creating and maintaining a fork of pkg/errors;
• using another fork which is maintained, such as https://gitlab.com/tozd/go/errors (doc: https://pkg.go.dev/gitlab.com/tozd/go/errors);
• using a package such as the one above, but in a limited way, only adding stack traces when necessary (see e.g. https://pkg.go.dev/gitlab.com/tozd/go/errors#hdr-Adding_a_stack_trace_to_an_error).

I guess the first step would be to evaluate if you actually need stack traces, and if yes, in which cases.

[jiechen0826]

Thanks for your thoughtful proposals. We really appreciate your efforts to improve the codebase.

Our team relies heavily on the stack trace functionality for debugging an internal component, so it's important for us to keep this capability. To ensure future flexibility and maintain the stack trace functionality, we suggest introducing an interface for the error type. For areas where stack traces are not needed, we can use the Go native error package, but in places where stack traces are currently used, we prefer to reimplement the stack tracing within the custom error interface.

Regarding your proposal to use a different third-party library, our concern is it could lead to similar issues in the future. Using an interface can ensure that any future changes to the error handling implementation will have minimal impact on the rest of the codebase.

We'd love to collaborate on incorporating these changes. If you're unable to make these adjustments, we'll follow up with our own PR and close this one.

Thanks again for your understanding and cooperation!