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

Consider dropping dependency on github.com/pkg/errors #3618

Open
imjasonh opened this issue May 17, 2022 · 3 comments
Open

Consider dropping dependency on github.com/pkg/errors #3618

imjasonh opened this issue May 17, 2022 · 3 comments

Comments

@imjasonh
Copy link
Contributor

https://github.com/pkg/errors is deprecated, archived, and in maintenance mode, since Go errors natively support wrapping since Go 1.13.

There are about 200 files in this repo that depend on this package (excluding vendor/):

git grep -l github.com/pkg/errors | grep -v ^vendor | wc -l
     196

It should be a fairly mechanical change:

  • errors.Wrap(err, "oh no") becomes fmt.Errorf("oh no: %w", err)
  • errors.New("oh no") becomes errors.New("oh no"), using the stdlib errors package.
  • errors.Errorf("oh %q", "no") becomes fmt.Errorf("oh %q", "no")

It may even be somewhat possible to automate, using x/tools/go/analysis (see sigstore/cosign#1887 (comment)).

Let me know if you'd be interested in considering a PR to make this change.

@thaJeztah
Copy link
Member

Unfortunately, Go's native error-wrapping is not a full replacement for pkg/errors, as it doesn't preserve a stack, which limits its usefulness.

We are considering to propose maintainers for the https://github.com/pkg/errors package (pkg/errors#245 TBD); overall the package is "feature complete", so likely not much maintenance will be needed. /cc @tonistiigi

Was there a specific reason you want the package to be removed?

@imjasonh
Copy link
Contributor Author

imjasonh commented May 17, 2022

Was there a specific reason you want the package to be removed?

Nothing specific exactly, but two broad categories of reasons:

  1. an unmaintained repo, even a "feature complete" one, presents a (small, theoretical) risk of having unaddressed vulnerabilities, compared to a well supported solution in Go's stdlib. I'm sure if there was a pkgerrors4shell-style vulnerability the original maintainers or the community would step up to fix it, but it would likely be much slower to seep out into the community than something in Go itself.

  2. Go tooling isn't aware that errors.Errorf takes a format string, and that any %s in it must be paired with a later arg. errors.Errorf("oh %s") is considered perfectly valid, though it would result in oh %!s(MISSING). Compare this with fmt.Errorf("oh %s"), which will fail when exercised during tests to alert callers to missing args, or extra args, etc. This also trickles out into IDE support for detecting missing args.

In any case, it's not an urgent need, and your answer is perfectly satisfactory. Especially so if you take on maintainership for it, since that would go toward solving (1) above.

If you ever become interested in this, my offer to send a PR stands. 😄

@mitar
Copy link

mitar commented Oct 9, 2023

Shameless plug: you can switch it to drop-in replacement gitlab.com/tozd/go/errors. It fixes many issues, is maintained, and supports modern Go's error patterns (sentinel errors, %w formatting, joined errors, etc.). It also provides some nice utility functions and structured details so that it is easy to extract dynamic data out of errors (instead of trying to get them out of formatted strings). Has improved error formatting and JSON marshaling of errors. It is interoperable with other errors packages and does not require a dependency on itself to extract data (e.g., stack trace) from errors.

BTW, go vet does complain on your example errors.Errorf("oh %s") for gitlab.com/tozd/go/errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants