Ugly user presentation when sm.lock exists due to abort

[rfay]

What version of Go (go version) and dep (git describe --tags) are you using?

go 1.8.3/osx
dep v0.1.0-215-g911cd22

What dep command did you run?

dep init (or really anything)

What did you expect to see?

Some interesting and informative results.

What did you see instead?

getSourceManager: cache lock file /Users/rfay/go/pkg/dep/sm.lock exists - another process crashed or is still running?

This was a simple result of me debugging through dep init and terminating the session, like a kill -9, but I'm sure it can happen to real people in lots of ways.

It turns out that the lock manager here is rolled for this particular code, and probably should be refactored to use something that is more general and has a fix technique. A slack thread from @sdboyer mentioned this issue, and Patrick Bennet suggested use of https://github.com/nightlyone/lockfile

There are two issues here:

• Refactor to a generalized lockfile manager
• Do an appropriate presentation to the user explaining how they can get out of this (minor) hell.

[matjam]

@sdboyer: I am tackling this.