I'm thinking about extending convertFault a small bit. If faultCode is present it should almost always come from koji. In such a case I would say it is +- safe to convert it to GenericError instead with the following code. There are probably some extreme cases where it could be misleading (faultCode is not from koji but from the underlying layer of xmlrpclib), but it should be safe in the most cases. Another improvement could be that faultCode range could be part of e.g. getKojiVersion(extended=True) which could return dict with version itself, coderange and maybe some additional info (like plugins enabled at hub).
About the importance - I think that the biggest problem wouldn't be the CLI - it is easy to see that it failed, but automation scripts and possible plugins. Their current GenericError handlers will stop working and just propagate exceptions further. So, wrapping everything as GenericError seems like a safer way to me.
Another options is the original one: Introduce new Exception ASAP but start using them in a ~year. I don't think it is that much helping. I see that (client) deployments are mostly in two categories - they don't update almost at all (old isolated boxes) and those which are updating for almost every release. It would help us in those small time windows (fedora upgraded koji hub, but users still don't have actual systems). It is still worth, but it can be reduced to +1 release (introduce exception in 1.27 and start them using in 1.28).
Mike, any thoughts?
for v in globals().values():
if isinstance(v, type(Exception)) and issubclass(v, GenericError) and \
code == getattr(v, 'faultCode', None):
ret = v(fault.faultString)
ret.fromFault = True
return ret
+ else:
+ raise GenericError(fault.faultString)