1615656 - mach addtest with mochitest-browser fails on macOS (`write() argument 1 must be unicode, not str`)

Status: RESOLVED DUPLICATE of bug 1614771

(Firefox Build System :: Mach Core, defect)

Description

[:Gijs (he/him)]

Full output:

$ ./mach addtest browser/components/customizableui/test/browser_flexible_space_area.js
Adding a test file at browser/components/customizableui/test/browser_flexible_space_area.js (suite `mochitest-browser-chrome`)
Error running mach:

    ['addtest', 'browser/components/customizableui/test/browser_flexible_space_area.js']

The error occurred in the implementation of the invoked mach command.

This should never occur and is likely a bug in the implementation of that
command.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

TypeError: write() argument 1 must be unicode, not str

  File "mozilla-unified/testing/mach_commands.py", line 210, in addtest
    f.write(template)

Not 100% sure why this isn't failing all the time / for everyone, or if I'm the only person using mach addtest or...

Comment 1

[:Gijs (he/him)]

Attachment: Bug 1615656 - decode templates read from disk if they're a binary type, r?ahal

Comment 2

[:Gijs (he/him)]

Regressed by: 1614771

FWIW, this was broken before bug 1614771 landed - I don't even have the revision from that bug in my local tree yet (ie I'm running a previous instance of m-c). It's possible the changes there would fix this issue for me on macOS...

Comment 3

[:Gijs (he/him)]

Looks like the commit from bug 1614771 does in fact fix this for me on my macOS machine.

:gbrown / :ahal is there any value in the patch here or should we just dupe this over to the py3 compat bug?

Comment 4

[Andrew Halberstadt [:ahal]]

Yeah, I'm kind of confused why it hadn't been reported yet either..

But this patch shouldn't be necessary anymore given bug 1614771. The template either comes from a string literal (Python 3 uses text type here already) or a file (Python 3 reads in text rather than bytes by default). So it makes total sense why running this with Python 3 would fix your issue.