IIUC, a failing task will raise the TaskError exception and the message will be shown, but the error from the task command will be hidden when running Copier via CLI, as it's not printed anymore but only accessible via the stdout/stderr attributes of the exception object. I think we should catch this exception in

Actually, the stdout/stderr will be None, since we did not capture them in subprocess.run(), and the output of the process still goes to the screen.

So we only need to output the message itself ("Task {command!r} returned non-zero exit status {returncode}.").
I believe that inheriting from UserMessageError will take care of that nicely?

I did all of the requested changes, except inheriting from CalledProcessError (see my comment above) - waiting for more input for that.
Hopefully i didn't do too much mess in the comments/review here 🙏

Done :)

@copier-org/maintainers What is the correct use of UserMessageError? When I check its occurrences, it seems this error is directly raised when it originates from an improper use of Copier that can be fixed by the user. One counter-example I've seen is a missing --unsafe/--trust flag which raises UnsafeTemplateError (which isn't a subclass of UserMessageError), although this problem can be resolved by a Copier user by adding the flag. What about a task error? Is it an error caused mainly by a template author which can't be fixed by a user? Is subclassing UserMessageError appropriate in this case? WDYT?

personally i assumed that UserMessageError is for any exception that should be reported to the user in a message.
if it is not the case, i will be happy for input about the way the @copier-org/maintainers prefer to use to report something to the user. is it the printf_exception function? something else? i don't want to add here a 2nd/3rd way to do something simple.

Hey @sisp , I saw you pinged the maintainers earlier regarding the UserMessageError—do you think it would be helpful to re-ping them, or should we proceed with an alternative approach?
Just want to make sure we align with the project’s conventions before finalizing this. Thanks!

What is the correct use of UserMessageError?

I would just be guessing so I'll leave that to @yajo 🙇

I'd like to wait for @yajo's opinion, as he is the lead maintainer with a long history developing Copier. All of us are working on Copier as time permits. Let's just wait for him to find time to share his thoughts.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.00%. Comparing base (82dd2cb) to head (8269c7b).
Report is 140 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1991      +/-   ##
==========================================
- Coverage   98.13%   98.00%   -0.13%     
==========================================
  Files          54       54              
  Lines        5832     5915      +83     
==========================================
+ Hits         5723     5797      +74     
- Misses        109      118       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

IIRC, UserMessageError is an error that should send a message to the user, just like the name says. It should not contain a traceback, because that would be confusing.

Just to clarify your comment, @yajo: Is it a valid pattern to let any exception (like TaskError) inherit from UserMessageError that shall print an error message to the user (i.e., errors that can be addressed by a template user, not author)? If so, should UnsafeTemplateError also inherit from UserMessageError? If yes, then we'd need to catch specific subclasses of UserMessageError such as UnsafeTemplateError in the CLI's exception handler first before catching UserMessageError to support exit codes other than 1 for some errors (like UnsafeTemplateError for which the CLI exits with code 4).

I guess the underlying question is: What is the meaning of UserMessageError and when to subclass it vs. just subclassing CopierError or other child classes? My confusion originates from an attempt to decouple API and CLI, such that (IMHO) exceptions shouldn't be designed with CLI-related error management in mind; CLI error handling should rather be an afterthought, as a CLI is merely one possible alternative interface to the Python API with its own peculiarities of managing errors.

@tsvikas Sorry for the delay. I've thought about the use of UserMessageError some more and believe the way you're using it here makes sense. 👍 Just one more thought: The new error handling for CLI users swallows all error information from the task process, which may make it difficult to understand the reason for the error. How about printing also stderr in addition to the generic message?

Thank you

I've implemented printing of stderr in TaskError. As a reminder, this won’t affect the current case, since the task execution runs without capturing, so both stdout and stderr are None (and were already printed to the screen). But it could be useful for future usages of TaskError.

it seems that the codecov is complaining about those lines being untested, which is true, because any task used currently will not capture the stderr -- this is only a future facing change.
I think that in order to test it we will need to write code that uses TaskError in a different way than in the codebase itself, which seems too artificial for a test.
Alternatively we can add ignore for codecov, or revert this change, or revert this change and assert stderr is None to prevent wrong usage of TaskError.

what do you think we should do?

Ah, I missed that stderr is always None and both stdout and stderr are printed unconditionally at the moment. Thanks for the reminder! Eventually, I think we should handle task error printing like pre-commit:

• When no error occurs, nothing is printed by default. Printing captured stdout/stderr is opt-in via the --verbose switch. In Copier, --quiet and a new --verbose switch would be mutually exclusive.
• When an error occurs, captured stdout/stderr is printed by default. In Copier, we would suppress it when our --quiet switch is used.

For our Python API users, TaskError's stdout/stderr attributes would contain the captured output of a failed task for further processing.

That said, I suggest to revert/drop db1a6dc (and f29ce78) to keep this PR focused on introducing the TaskError exception and address further enhancements in subsequent PRs. Sorry for the confusion.

done :)