macOS app-package merging doesn't preserve executable permissions

[tower-jay]

Describe the bug

When using Selenium WebDriver in a BeeWare app, auto-downloading of the Chrome WebDriver fails in Briefcase version 0.3.16. The same functionality works as expected in Briefcase v0.3.15.

Steps to reproduce

1. Create a simple BeeWare app that uses Selenium WebDriver.
2. Package the app using Briefcase v0.3.16.
3. Run the app and trigger the Selenium code (e.g., by clicking a button in the app).

Expected behavior

The Chrome WebDriver should auto-download and the Selenium code should execute without issues.

Screenshots

No response

Environment

• Operating System: macOS 13.4.1
• Platform: x86_64
• Python version: 3.11
• Software versions:
  • Briefcase: 0.3.16
  • Toga: 0.3.1
  • Selenium 4.14.0

Logs

/Users/jay/Desktop/pythonProject/test1/build/test1/macos/app/test.app/Contents/Resources/app_packages/selenium/webdriver/common/driver_finder.py", line 41, in get_path
    raise NoSuchDriverException(msg) from err
selenium.common.exceptions.NoSuchDriverException: Message: Unable to obtain driver for chrome using Selenium Manager.; For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors/driver_location
"

Additional context

• The issue does not occur when using Briefcase v0.3.15. I tested by installing v0.3.15 from the start and I also tested downgrading in the existing project. Both of these methods resolved the issue.
• Selenium is specified in pyproject.toml.

[freakboy3742]

Thanks for the report.

I've identified the cause. Of the changes introduced in Briefcase 0.3.16 is an app-packages merging tool that ensures that any installed requirements are universal, regardless of how they're published. One of the unintended side effects is that executables that are included in a package aren't copied with their executable permissions.

The workaround is to run:

chmod 755 build/seleniumtest/macos/app/Selenium\ Test.app/Contents/Resources/app_packages/selenium/webdriver/common/macos/selenium-manager 

after running briefcase create (substituting the name of your app as appropriate).

It's also worth noting that the selenium wheel is tagged as a py3-none-any wheel, but it contains platform-dependent binary components. It's one of the binary components that is causing a problem here - the selenium-manager binary. In this case, I don't think a correctly tagged binary would alter any of Briefcase's behavior, but it definitely could cause problems - for example, this package would read as being entirely viable on iOS and Android - and it won't be. It also provides a 'linux' binary, but there's no indication what manylinux specification that binary is compatible with.

[tower-jay]

Thank you for the quick response and identifying the issue. I applied the workaround you suggested, and it did the trick! I appreciate the heads-up about Selenium's wheel tagging as well.