UNSAT exception design about resolvelib HOT 3 CLOSED

Personally I don’t think it’s the library’s place to provide a human-readable output. ResolutionImpossible is intended to be caught and handled by the outer call stack, and therefore should provide structured information, not rendered. It may be worthwhile to have a module like resolvelib.debugging that formats an exception into pretty output for debugging purposes, but I feel that should not live directly on the exception type.

I think it’s a good idea for the exception to have the state in the resolver. But this needs to be done extremely carefully and in an abstract way, and not tied with the backtracking nature of the resolver. Otherwise it will be impossible to change the resolution internals without the caller knowing, which is an important goal to this project.

from resolvelib.

@pfmoore @uranusjr notes from a past @pradyunsg about what to do for the ResolutionImpossible exception. :3

from resolvelib.

Closing this out since I think we've figured this out. For posterity, I recently described what we did for this in spack/spack#36502 (comment).

from resolvelib.