proposal: drop github.com/pkg/errors as a dependency

[pwaller]

@mewmew and I had a brief thought about reducing external dependencies. This is a reminder to discuss this further.

We're currently thinking that pkg/errors doesn't bring much to the table and we can drop it. Dropping it should be fairly transparent to any users. Part of the motivation is to reduce dependencies, and the other part is from the readme of pkg/errors:

With the upcoming Go2 error proposals this package is moving into maintenance mode.

References:

• Replace errutil with pkg/errors mewkiz/flac#22
• proposal: Go 2 error values golang/go#29934 (go 2 errors proposal which was tentatively accepted 3 days ago)

[hosewiejacke]

SGTM. Here are some stats: $ cd $GOPATH/src/github.com/llir/llvm $ ag --nofilename --nobreak -o --ignore testdata "errors\.\w+" \ | sort \ | uniq -c 93 errors.Errorf 3 errors.New 495 errors.WithStack 1 errors.Wrapf

[mewmew]

For added context, I do find the errors.WithStack very useful. Then you get to know what part of the code failed than just getting a unexpected EOF error.

So, rather than just removing the use of pkg/errors, I would much rather replace it with whatever becomes the accepted standard way to handle errors in Go 2/Go 1.13.

[mewmew]

Marking this as a future milestone until the error handling story of Go has been fully unwrapped. As of 2019-06-30, https://blog.golang.org/go2-next-steps states that stack-trace information will not enter Go 1.13. Therefore, we will wait at least until Go 1.14 before replacing pkg/errors, since the error stack traces are the primary feature we rely on from pkg/errors.

[dannypsnl]

@mewmew any updates here? since Go 1.14 has passed for a long time XD

[mewmew]

@mewmew any updates here? since Go 1.14 has passed for a long time XD

Do you know if the standard library error handling provides stack traces for errors in a good way? This is the reason we keep using github.com/pkg/errors. E.g. errors.WithStack

[mitar]

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 is interoperable with other errors packages and does not require a dependency on itself to extract data (e.g., stack trace) from errors.

[mewmew]

Hi @mitar,

Thanks for making us aware of your fork of the pkg/errors package :) Looks like you've put in a lot of effort to fix some of the issues identified in pkg/errors. I don't think we've run into any of the outlined issues ourselves, but it's good to know they are present in the no-longer maintained pkg/errors package.

The main idea with this issue (as outlined by @pwaller in #73 (comment)) was to reduce the need of external dependencies in llir/llvm, so switching from pkg/errors to gitlab.com/tozd/go/errors would not solve that issue.

That being said, it's definitely good to know that the gitlab.com/tozd/go/errors package exist. It may come in handy for other projects.

Cheers,
Robin

[mitar]

Thank you for the reply. From my experience writing a library, it is tricky to have your own stack traces because how fragmented is support for stack traces among different libraries. So not sure how reasonable is to roll your own solution if you do want stack traces yourself. Besides just recording stack traces, formatting, and JSON serialization of stack traces, there is also interoperability with other packages. If some of your dependencies use a different way to record a stack trace, it is useful to be able to extract and reuse that stack trace (instead of storing your own, shorter stack trace at the point you call into that library).

BTW, my package is not fork of pkg/errors but a fresh implementation, keeping its API for compatibility. It also behaves similarly so it can be used as drop-in replacement.

Anyway, I just wanted to bring the package to your radar and clarify these two points. I otherwise completely understand that minimizing dependencies is important. We were doing the same but then decided to open source errors package once pkg/errors got archived.

[mewmew]

Thank you for the reply. From my experience writing a library, it is tricky to have your own stack traces because how fragmented is support for stack traces among different libraries. So not sure how reasonable is to roll your own solution if you do want stack traces yourself. Besides just recording stack traces, formatting, and JSON serialization of stack traces, there is also interoperability with other packages. If some of your dependencies use a different way to record a stack trace, it is useful to be able to extract and reuse that stack trace (instead of storing your own, shorter stack trace at the point you call into that library).

I can imagine that dealing with stack traces may be difficulty, especially in a cross-platform and standardized manner.

I'm certain that we won't be "rolling our own" implementation for handling stack traces. So either we'll rely on external libraries to handle tracking of stack traces, use the Go standard library for it (once/if such support is added for error stack traces) or simply remove the use of stack traces to avoid external dependencies.

As you can see from the creation time of this issue, the ball has not been moving since the situation as is is "good enough". Should we start running into concrete issues with pkg/errors than knowing that gitlab.com/tozd/go/errors exists is definitely helpful.

BTW, my package is not fork of pkg/errors but a fresh implementation, keeping its API for compatibility. It also behaves similarly so it can be used as drop-in replacement.

Sorry for the misunderstanding on my part. Good to know that gitlab.com/tozd/go/errors kept API compatibility towards pkg/errors, while being a fresh implementation.

Anyway, I just wanted to bring the package to your radar and clarify these two points. I otherwise completely understand that minimizing dependencies is important. We were doing the same but then decided to open source errors package once pkg/errors got archived.

Thanks @mitar for sharing your work with the open source community. Definitely appreciate it!

On a related note, have you seen the capslock tool? It can be used for static analysis of dependencies to determine what capabilities they use. A very handy tool, even though it's still in some early alpha stage.

Happy coding!

Cheers,
Robin