Package errors looking for new maintainers #245
Comments
|
Curious, this package is under the 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 Edit: a big thank you for open sourcing, maintaining and resolving issues and bugs! Open source works best when we collaborate. |
|
@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. |
|
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. |
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]>
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]>
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]>
@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. |
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)
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
The text was updated successfully, but these errors were encountered: