briefcase: Suggession: Add error capture flag to "run" command

Hey, How are you doing? 😃

I have a problem where my program is working just fine when I run it with briefcase dev but fails on briefcase run. Since the run command doesn’t capture errors, I cannot see the reason for the failure.

As I’ve seen the run command starts a process using the subprocess command. To help developers debug problems like this I suggest add a flag capture-errors that run the subprocess in this following way (example from msi.py):

        error_io = io.StringIO()
        try:
            print()
            self.subprocess.run(
                [
                    str(self.binary_path(app) / 'src' / 'python' / 'pythonw.exe'),
                    "-m", app.module_name
                ],
                check=True,
                stderr=error_io
            )
        except subprocess.CalledProcessError:
            print(error_io.getvalue())
            raise BriefcaseCommandError(
                "Unable to start app {app.app_name}.".format(app=app)
            )

In that way, the errors will be printed and we could see the problem. In the absence of this flag, it will run it without the error_io

What do you think about the solution? Once you’ll approve it, I’ll implement it.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (14 by maintainers)

Most upvoted comments

Hi @saroad2 ! I ran into a similar problem recently, and I have a suggestion. @freakboy3742 made most of the design decisions in briefcase and may have a different take; whatever he says is fine with me, too.

My suggestion is that when briefcase starts any subprocess, it always can store a debug log in ~/.briefcase. If the command fails, briefcase prints the path to that debug log. If the subprocess succeeded, briefcase can delete the log file. This avoids the possibility of memory bloat, though it introduces the possibility that the command will print so much output as to fill up the disk, but I think that is less likely than filling up RAM.

I like this because it would have helped me debug my Android changes recently.

We could make the debug log filename could be different for each execution, or we could reuse the same filename over and over; I have no real opinion on this.

I suggest we write a helper function around subprocess that implements this logic, rather than directly calling subprocess.run(). An initial implementation could adjust just one or two places to use this new mechanism, to see if we really do like it.

paulproteus on Mar 9, 2020