You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On macOS when loading libdiscid and libdiscid.dylib is both available system wide (e.g. in /usr/local/) and local to the application, the system wide install is preferred.
However, especially when running from a bundled app it might be preferable to use the bundled version to be sure to get exactly the expected version.
Having the local version being preferred seems to have been the intention of #16, however it does not currently work this way.
Probably it is not always preferable to use a local version. Also the location might be very special.
I checked for a macOS app created with PyInstaller: os.getcwd() in this case is always /. What I really would like to check for Picard is the directory where sys.executable is located, if the app is bundled (sys.frozen == True).
Maybe it's not ideal to make any hardcoded assumptions of the library location, but instead provide some mechanism to specify the library location.
So for Picard I decided to set the DYLD_FALLBACK_LIBRARY_PATH environment variable so libraries are searched in os.path.dirname(sys.executable). At least this fixes the issue in the code where we actually now where to look. See metabrainz/picard#1346
Not quite sure if this can / should be generically fixed in python-discid. I leave this issue open for comments.
On macOS when loading libdiscid and libdiscid.dylib is both available system wide (e.g. in /usr/local/) and local to the application, the system wide install is preferred.
However, especially when running from a bundled app it might be preferable to use the bundled version to be sure to get exactly the expected version.
Having the local version being preferred seems to have been the intention of #16, however it does not currently work this way.
Picard is affected by this, see https://tickets.metabrainz.org/browse/PICARD-1653
The text was updated successfully, but these errors were encountered: