This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author shakfu
Recipients eric.snow, mathias, ncoghlan, ronaldoussoren, shakfu, vstinner
Date 2022-03-14.15:23:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thanks, Victor. I can imagine 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.
Date User Action Args
2022-03-14 15:23:11shakfusetrecipients: + shakfu, ronaldoussoren, ncoghlan, vstinner, eric.snow, mathias
2022-03-14 15:23:11shakfusetmessageid: <>
2022-03-14 15:23:11shakfulinkissue18309 messages
2022-03-14 15:23:11shakfucreate