Error and failure reporting #288
Description
Dependency management is a complex problem. We have tried to eliminate incidental complexities in dep, but the fundamental challenges remain. Consequently, dep has complex failure modes. We need to mitigate the confusion arising from such failures by making errors and failures as comprehensible as possible.
The primary difficulty with these errors is reporting them to the user in a way that links cause and effect, so that the errors are comprehensible and actionable.
There are three main classes of errors to deal with:
- Bad inputs: problems with either the user's CLI input, or the state of thecurrent project (manifest/lock/code) on disk. These are relatively easy, as these failure modes involve only local (non-network, non-dependency) information.
- IO problems: any of the classic errors that can occur with network or disk interaction. Network/name resolution failures are particularly important for correctness.
- Solve failures: when the solver (gps) fails to find an acceptable dependency set, it (usually) reports a set of errors for each version of the project it failed to satisfy. This is the really hard one - hard enough that gps just as a meta-issue for it right now: Handle errors more sanely sdboyer/gps#20
It's quite likely that getting the errors really good will be something we iterate on for a long time to come. The criteria we need to meet here is mostly that we've put handling in place for the easier and more common cases with errors, as well as building some rules and patterns that provide structure and prevent future, iterative work from being totally ad hoc.