Getting an error when pyinstaller files are installed on mac osx under myapp.app.

[zapta]

TL;DR, pyinstaller app fails when installed under an OSX .app dir.

Pyinstaller generated for me files which I was able to install and use successfully on mac osx using an InstallBuilder builder. When I tried to do the same with VeloPak installer (open source), the app failed with the error below. The difference between the two installations is that InstallBuilder installs under /Applications/my-app-name while velopak installs under /Applications/my-app-name.app (noice the extra .app extension) and this breaks the pyinstaller app.

Here is a log that shows that removing the .app extension from the install app 'fixes' the problem. https://pastebin.com/nK67herM

Any suggestions on how to make an pyinstaller app to run on OSX also in .app installations?

$ /Applications/Apio\ 0.9.6.app/Contents/MacOS/apio 
[PYI-89502:ERROR] Failed to load Python shared library '/Applications/Apio 0.9.6.app/Contents/Frameworks/Python': dlopen: dlopen(/Applications/Apio 0.9.6.app/Contents/Frameworks/Python, 0x000A): tried: '/Applications/Apio 0.9.6.app/Contents/Frameworks/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Apio 0.9.6.app/Contents/Frameworks/Python' (no such file), '/Applications/Apio 0.9.6.app/Contents/Frameworks/Python' (no such file)
/projects/apio-dev/repo$

[bwoodsend]

PyInstaller makes .app bundles if you give it the --windowed mode flag.

[zapta]

@bwoodsend, when I tried to add --windowed to the command line I got the error below.

Also, our app is a command line app, not a GUI, is --windowed is an appropriate choice for it? Or, is it possible that osx .app installation doesn't support CLI apps at all? ChatGpt says that .app it's not preferred for CLI apps but doesn't say it's not allowed. (I am trying to find a configuraiton in which pyinstaller and velopak can work together).

Run: ['pyinstaller', '--windowed', '--distpath', '_dist', '--workpath', '_build', './apio.spec']
106 INFO: PyInstaller: 6.11.1, contrib hooks: 2024.11
106 INFO: Python: 3.13.1
116 INFO: Platform: macOS-14.5-arm64-arm-64bit-Mach-O
116 INFO: Python environment: /Library/Frameworks/Python.framework/Versions/3.13
option(s) not allowed:
  --console/--nowindowed/--windowed/--noconsole
makespec options not valid when a .spec file is given

[zapta]

I tested two simple hello world apps with the velopack osx bundle installer (sources in the zip files below). One with C and one with Python + Pyinstaller. The installed C app was functional while the one with Python + Pyinstaller failed with an error.

This suggest that the .app bundle format does support command line apps and that the issue is specific to pyinstaller.

Running the C app.

$ /Applications/cli.app/Contents/MacOS/app.bin 
Hello, world!

Running the Python + Pyinstaller app.

$ /Applications/app.app/Contents/MacOS/
UpdateMac  _internal/ app        
/projects/apio-installers/repo/velopack-test-py$ /Applications/app.app/Contents/MacOS/app 
[PYI-93385:ERROR] Failed to load Python shared library '/Applications/app.app/Contents/Frameworks/Python': dlopen: dlopen(/Applications/app.app/Contents/Frameworks/Python, 0x000A): tried: '/Applications/app.app/Contents/Frameworks/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/app.app/Contents/Frameworks/Python' (no such file), '/Applications/app.app/Contents/Frameworks/Python' (no such file)

The sources of the two examples. Require velopack 'vpk' command installed.
velopack-test-c.zip
velopack-test-py.zip

EDIT: Two more thing I found out

1. If pyinstaller generates an app in onefile mode it does work.
3. The error I get with the onedir mode running in an .app bundle is the same as if I delete the _internal directory that pyinstaller generates and run the binary without it (outside of the installed bundle). It seems to me that the installed app binary can't find the _internal directory which is sibling to it in the installed bundle.

[rokm]

@bwoodsend, when I tried to add --windowed to the command line I got the error below.

That's because you cannot use this option when building from .spec - only when generating a .spec or building from a .py file (which generates .spec on-the-fly).

[rokm]

As Brénainn mentioned, PyInstaller natively supports generation of macOS .app bundles.

Therefore, our bootloader executable tries to detect when it is running in .app bundle mode, by checking its location. If the parent directory matches Contents/MacOS, it assumes that it is running in the .app bundle mode. And in that mode, it assumes that the application's files are located in Contents/Frameworks and Contents/Resources, as mandated by Apple.

[PYI-93385:ERROR] Failed to load Python shared library '/Applications/app.app/Contents/Frameworks/Python': dlopen: dlopen(/Applications/app.app/Contents/Frameworks/Python, 0x000A): tried: '/Applications/app.app/Contents/Frameworks/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/app.app/Contents/Frameworks/Python' (no such file), '/Applications/app.app/Contents/Frameworks/Python' (no such file)

The error you are getting implies that VeloPak simply took the contents of the POSIX PyInstaller onedir build, and put it under Contents/MacOS; therefore, the Python shared library cannot be found (as we now assume it to be under Contents/Frameworks. Note that putting everything under Contents/MacOS directory runs afoul of Apple's rules for file locations in .app bundles, and that your bundle likely cannot be signed and notarized.

In short, you cannot take a regular POSIX build and manually turn it into an .app bundle; there's a reason why PyInstaller has its own built-in target for .app bundles...

[zapta]

Thanks @rokm. Yes, velopack placed _internal in Context/MacOS.

Per your suggestion, We created a .app bundle with pyinstaller, made it a .dmg with create-dmg from brew, installed it with dragging and /Applications/app.app/Contents/MacOS/app does work (good).

The osx issue we have now is that the /Applications/app.app/Contents/MacOS/app is not added automatically to the PATH. Any suggestions on how to do that?

[rokm]

The osx issue we have now is that the /Applications/app.app/Contents/MacOS/app is not added automatically to the PATH. Any suggestions on how to do that?

That's not how .app bundles work - those are typically GUI applications, and are launched via double-click in the Finder. (They are kind of like Windows GUI programs in that sense). These are installed from .dmg via drag & drop installation procedure.

I think you can also create a .pkg (in a .zip or .dmg) that has a guided installer. This could probably add the target path to PATH, or perhaps create a symlink to application's executable to /usr/local/bin (I think that's what python.org python installer does?).

[zapta]

@rokm, I created a .pkg guided installation and it works. It contains a custom postinstall script that sets the path (or set a symlink if desired).

BTW, pyinstall creates two directories in the dist directory, app and app.app. I am create the package with the first one and it installed in /Applications as a 'folder' application rather than a bundle application. It seems to be more user friendly for cli apps.

pkgbuild \
  --root "_dist"\
  --install-location "/Applications" \
  --identifier "com.example.myapp" \
  --version "1.0.0" \
  --scripts scripts \
  --ownership recommended \
  "MyApp.pkg"

I think we are good with the osx installer. Thanks @rokm and @bwoodsend for your help!

[rokm]

BTW, pyinstall creates two directories in the dist directory, app and app.app. I am create the package with the first one and it installed in /Applications as a 'folder' application rather than a bundle application. It seems to be more user friendly for cli apps.

Yes, that's because when you use --windowed mode, the spec file contains both COLLECT and BUNDLE targets; the first creates a onedir POSIX build, and the second an .app bundle. If you do not need the .app bundle, you can remove the BUNDLE target from the .spec.

[zapta]

We have a working macosx installer. Thanks for the help.