all: use errgo instead of fmt.Errorf

all: use errgo instead of fmt.Errorf

Also migrate away from github.com/errgo/errgo.

Almost entirely an automatic change. In general, errors.Tracef is
almost exactly equivalent to fmt.Errorf - the only difference
being the exact type (which isn't exported by the std
errors package) and the fact that DeepEquals won't
work between two errors created in different places, because
the errgo errors have embedded source-location info.

The very few manual changes include:
- fixes where the tests assume that errors.New() is DeepEqual to errors.New()
- one place where a variable "errors" clashed with the package of that name.
- one place (agent/agent.go) where errgo.Trace was used - that's now reverted.

The only files with manual interventions are these:

  agent/agent.go
  cmd/jujud/agent_test.go
  cmd/jujud/machine.go
  testing/locking_test.go
  utils/apt_test.go
  worker/uniter/uniter.go

https://code.launchpad.net/~rogpeppe/juju-core/510-errorf-errgo/+merge/209074

(do not edit description out of merge proposal)

[rog, 2014-03-03 14:43:17]

Please take a look.

[rog, 2014-03-03 14:46:36]

Please take a look.

[natefinch, 2014-03-03 15:59:52]

nlgtm - the path to errgo should be github.com/juju/errgo ... the subdirectory
serves no purpose, except to confuse people into thinking there might be code in
the parent directory.

Also, the package should be imported as errgo everywhere. This prevents any
possibility of confusion with the standard library errors package, and means
that if you see errors.New somewhere... you know it's wrong, as opposed to not
knowing until you go look at the imports to determine which errors.new is being
called.

It's basically never a good idea to write a package with the same name as a
standard library package, especially in this case when there's a perfectly
sensible alternative that only makes the code more clear.

Otherwise, the code looks fine.

[natefinch, 2014-03-03 16:02:05]

On 2014/03/03 15:59:52, nate.finch wrote:
> nlgtm - the path to errgo should be github.com/juju/errgo ... the subdirectory
> serves no purpose, except to confuse people into thinking there might be code
in
> the parent directory.
> 
> Also, the package should be imported as errgo everywhere. This prevents any
> possibility of confusion with the standard library errors package, and means
> that if you see errors.New somewhere... you know it's wrong, as opposed to not
> knowing until you go look at the imports to determine which errors.new is
being
> called.
> 
> It's basically never a good idea to write a package with the same name as a
> standard library package, especially in this case when there's a perfectly
> sensible alternative that only makes the code more clear.
> 
> Otherwise, the code looks fine.

arg, the above should be a not lgtm ... I guess the abbreviation doesn't work
correctly :/

[natefinch, 2014-03-03 16:02:05]

On 2014/03/03 15:59:52, nate.finch wrote:
> nlgtm - the path to errgo should be github.com/juju/errgo ... the subdirectory
> serves no purpose, except to confuse people into thinking there might be code
in
> the parent directory.
> 
> Also, the package should be imported as errgo everywhere. This prevents any
> possibility of confusion with the standard library errors package, and means
> that if you see errors.New somewhere... you know it's wrong, as opposed to not
> knowing until you go look at the imports to determine which errors.new is
being
> called.
> 
> It's basically never a good idea to write a package with the same name as a
> standard library package, especially in this case when there's a perfectly
> sensible alternative that only makes the code more clear.
> 
> Otherwise, the code looks fine.

arg, the above should be a not lgtm ... I guess the abbreviation doesn't work
correctly :/