Shakeeb Alireza <shakeeb.alir...@gmail.com> added the comment:
Thanks, Victor. I can imagine getpath.py will be more hackable (even if it is frozen). Still, it replicates the old algorithm: # Before any searches are done, the location of the executable is # determined. If Py_SetPath() was called, or if we are running on # Windows, the 'real_executable' path is used (if known). Otherwise, # we use the config-specified program name or default to argv[0]. In my case (and I think for Mathias), the executable is a non python application and what is actually dynamically linking to libpythonX.Y.dylib (built via --enable-shared) is a c-based plugin (which calls PyInitialize()), and these two are only aware of their relative locations via the @rpath, @loader_path mechanism. Currently, in this scenario, libpythonX.Y.dylib doesn't know here pythonhome is unless explicitly told via PySetPath() or it defaults to the hardcoded sys.prefix . If this is to be relocatable, then PySetPath() should be able to handle relative paths. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18309> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
