Skip to content
This repository has been archived by the owner on Dec 1, 2021. It is now read-only.

Package errors looking for new maintainers #245

Open
davecheney opened this issue Sep 4, 2021 · 4 comments
Open

Package errors looking for new maintainers #245

davecheney opened this issue Sep 4, 2021 · 4 comments

Comments

@davecheney
Copy link
Member

Hello,

Quite clearly this package has been unmaintained for a long time. There are two main reasons for this (along with several others — waves in the general direction of life)

  1. I had hoped that with the integration of some of the ideas from this package into Go 1.8 (I think) then the use of and need for this package would decrease. Sadly for whatever reason Go errors did not obtain the feature that this package was built for — stack traces on errors, so the need for this package remained.
  2. I no longer use this package, in fact I no longer wrap errors. This sounds like a grandiose claim, and it may be my quirky coding style (my other views on error handling are hardly commonplace), so I don’t mean this comment to be a judgement on anyone who uses this package and enjoys it. It’s simply that it’s hard to make time to work on something which I no longer believe in.

Having got this off my chest, I recognise that this package holds a useful place in the Go ecosystem so it deserves more attention than it’s got over the last few years.

To that end, I welcome expressions of interest in the comments below.

Thank you

@mfridman
Copy link

mfridman commented Sep 4, 2021

Curious, this package is under the pkg organization with a few well-respected folks from the Go community (at least those that are public), could them collectively lightly maintain pkg/errors in its current form? Having used this package from the very beginning one could argue its feature complete and doesn't need much maintenance.

For what it's worth I still use this package, and will continue to do so until the standard library is at least feature parity with pkg/errors. This was the premise of xerrors, but in my opinion it removed too many useful features, namely stack traces on errors.

Edit: a big thank you for open sourcing, maintaining and resolving issues and bugs! Open source works best when we collaborate.

@davecheney
Copy link
Member Author

@mfridman you are correct that this package pretty much does what it says on the tin, and at this point can’t really do something different without the trauma of introducing errors/v2.

Perhaps the better solution is to archive this project and let development continue in forks.

@mfridman
Copy link

mfridman commented Sep 4, 2021

Pretty much any way its sliced will be a breaking change. The ideal scenario would have been for the Go team to provide a smooth transition to the standard library while offering the most common feature set among error packages, but that's not here nor there.

My vote goes towards sunsetting (archiving) this package with a short blurb on what this package is and maybe a small blurb on the history of how we got here.

If a fork spawns, and gains popularity .. it is what it is. But I'd rather see this package live another day in its current form, as opposed to new maintainers who (quite often) get feature happy.

negz added a commit to negz/crossplane-runtime that referenced this issue Sep 9, 2021
Go introduced a 'native' way to wrap errors back in v1.13. At that point we were
already using github.com/pkg/errors to 'wrap' errors with context, and we never
got around to migrating. In addition to pure inertia, I've personally avoided
making the switch because I prefer the github.com/pkg/errors API. Specifically I
like that errors.Wrap handles the "outer context: inner context" error format
that Go uses by convention, and that errors.Wrap will return nil when passed a
nil error.

Given that github.com/pkg/errors has long been in maintenance mode, and is (per
pkg/errors#245) no longer used by its original author
now seems as good a time as any to migrate. This commit attempts to ease that
migration for the Crossplane project - and to retain the nice API - by adding a
package that acts as a small github.com/pkg/errors style shim layer around the
stdlib pkg/errors (and friends, like fmt.Errorf).

Signed-off-by: Nic Cope <[email protected]>
negz added a commit to negz/crossplane-runtime that referenced this issue Sep 9, 2021
Go introduced a 'native' way to wrap errors back in v1.13. At that point we were
already using github.com/pkg/errors to 'wrap' errors with context, and we never
got around to migrating. In addition to pure inertia, I've personally avoided
making the switch because I prefer the github.com/pkg/errors API. Specifically I
like that errors.Wrap handles the "outer context: inner context" error format
that Go uses by convention, and that errors.Wrap will return nil when passed a
nil error.

Given that github.com/pkg/errors has long been in maintenance mode, and is (per
pkg/errors#245) no longer used by its original author
now seems as good a time as any to migrate. This commit attempts to ease that
migration for the Crossplane project - and to retain the nice API - by adding a
package that acts as a small github.com/pkg/errors style shim layer around the
stdlib pkg/errors (and friends, like fmt.Errorf).

Signed-off-by: Nic Cope <[email protected]>
negz added a commit to negz/crossplane-runtime that referenced this issue Sep 9, 2021
Go introduced a 'native' way to wrap errors back in v1.13. At that point we were
already using github.com/pkg/errors to 'wrap' errors with context, and we never
got around to migrating. In addition to pure inertia, I've personally avoided
making the switch because I prefer the github.com/pkg/errors API. Specifically I
like that errors.Wrap handles the "outer context: inner context" error format
that Go uses by convention, and that errors.Wrap will return nil when passed a
nil error.

Given that github.com/pkg/errors has long been in maintenance mode, and is (per
pkg/errors#245) no longer used by its original author
now seems as good a time as any to migrate. This commit attempts to ease that
migration for the Crossplane project - and to retain the nice API - by adding a
package that acts as a small github.com/pkg/errors style shim layer around the
stdlib pkg/errors (and friends, like fmt.Errorf).

Signed-off-by: Nic Cope <[email protected]>
@jackwhelpton
Copy link

I no longer use this package, in fact I no longer wrap errors. This sounds like a grandiose claim, and it may be my quirky coding style (my other views on error handling are hardly commonplace), so I don’t mean this comment to be a judgement on anyone who uses this package and enjoys it. It’s simply that it’s hard to make time to work on something which I no longer believe in.

@davecheney: I'd be very interested in reading a blog post on this if life ever permits again; although you may find your error handling ideas quirky, your previous writings on the subject have been required reading for our team.

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

No branches or pull requests

3 participants