Skip to content

fix(setup): resolve macOS code-signing errors when installing pip packages#1231

Open
silverl wants to merge 1 commit intoDLR-RM:mainfrom
silverl:iss_768_macos_app_bundle_permissions
Open

fix(setup): resolve macOS code-signing errors when installing pip packages#1231
silverl wants to merge 1 commit intoDLR-RM:mainfrom
silverl:iss_768_macos_app_bundle_permissions

Conversation

@silverl
Copy link
Copy Markdown

@silverl silverl commented Feb 19, 2026

Summary

Fixes #768

On macOS, BlenderProc fails on first run with PermissionError: [Errno 1] Operation not permitted because the custom-python-packages directory is created inside the sealed Blender.app bundle. A second failure occurs when pip install --upgrade pip destroys pip entirely — it uninstalls the old version (succeeds), tries to install the new version into the read-only bundle (fails), and the rollback also fails, leaving no working pip.

This PR fixes both issues:

  1. Package path relocation — When the default custom-python-packages path doesn't already exist and its parent isn't writable, walk up the path to find the .app boundary and place the directory as a sibling outside the bundle. If the directory already exists (e.g. user previously granted Full Disk Access to their terminal), the original path is preserved for backward compatibility.

  2. Pip upgrade recovery — After attempting the pip upgrade, verify pip still works via pip --version. If it was destroyed, re-run ensurepip to restore the bundled version. This is a no-op on Linux/Windows where the upgrade succeeds normally.

Test plan

  • Generated synthetic images on macOS 26.3 (Tahoe), Apple M4 Pro, Blender 4.2.1 — BlenderProc installs packages and renders successfully without granting Full Disk Access
  • Verify no behavior change on Linux (default path should remain inside the Blender directory)
  • Verify no behavior change for macOS users who have already granted Full Disk Access (existing custom-python-packages directory inside .app is respected)

…kages

On my Mac (M4 Pro, macOS 26.3 Tahoe), BlenderProc failed on first run
with "Operation not permitted" errors. Two issues:

1. custom-python-packages is created inside the Blender.app bundle,
   which macOS seals via code-signing. Any attempt to mkdir or write
   files inside the .app fails with PermissionError.

2. The pip upgrade (pip install --upgrade pip) destroys pip entirely.
   What happens: pip first uninstalls itself (e.g. 23.2.1) from
   Blender's site-packages — deletion succeeds. Then it tries to
   install the new version into the same sealed location — which
   fails. The rollback also fails because the directory is still
   read-only. Result: no working pip at all, and every subsequent
   package install breaks with "No module named pip".

Fix (1): when the default packages path doesn't already exist and its
parent directory isn't writable, walk up the path to find the .app
boundary and place custom-python-packages as a sibling directory
outside the bundle. If the directory already exists (e.g. user
previously granted Full Disk Access), the original path is preserved
for backward compatibility.

Fix (2): after attempting the pip upgrade, verify pip still works. If
it was destroyed by a failed upgrade, re-run ensurepip to restore the
bundled version. This is a no-op on systems where the upgrade succeeds.

fixes DLR-RM#768
@cla-bot
Copy link
Copy Markdown

cla-bot bot commented Feb 19, 2026

For contributing to BlenderProc you need to sign our Contributor License Agreement. As an individual please sign CLA_individuals.pdf, as a company please sign CLA_entities.pdf and send it to blenderproc@dlr.de

@silverl
Copy link
Copy Markdown
Author

silverl commented Mar 4, 2026

I mailed the contributor license on Feb 20, 2026.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Show warning on mac when custom pip package path is not writable

1 participant