This again exposes the internal error below. i.e. the user doesn't know what GPU type config should be provided or default, never nil means. We probably don't want to handle an error here and instead do it in the gpuTypesFromConfig function.

We will eventually need to refactor the error handling. A good convention might be to nevel os.Exit or print ui.* from a package that is not cmd. i.e. the cmd package handles all user interface things while sub return meaningful errors.

For now, let's just fix this error to not expose internal semantics.

I would probably lean towards doing a combination of this and using a function to handle errors on the CLI that only prints errors that are intended to be directed at the user.

I don't think we need to hide the error handling behind too many functions. It makes code harder to read. The calling function has context of what the error might be (eg. Invalid GPU type) and is therefore the best place to print an error to the user. Redirecting to another function will result in more parsing of what the actual error was.

We can adopt a simple convention that anytime we make a request to a function that's not in the cmd package, we handle the result error on the spot.

Updated with this approach