René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Inconsistent platform support for taking the loaded `libpython` path into account in `getpath`","articleBody":"# Bug report\n\n### Bug description:\n\nThe current `getpath.py` code tries determining `base_prefix`/`base_exec_prefix` by searching the location of the `libpython` library loaded in the current process, falling back to the location of the Python interpreter executable.\n\nhttps://github.com/python/cpython/blob/7900a85019457c14e8c6abac532846bc9f26760d/Modules/getpath.py#L559-L594\n\nLooking at the location of the `libpython` library in use first makes sense, as that is more reliable than looking at interpreter location — it works when embedding, where there isn't any interpreter executable, it works when the executable is not on `base_prefix`, etc. However, this is only currently supported on Windows and macOS framework builds.\n\nhttps://github.com/python/cpython/blob/7b8bd3b2b81f4aca63c5b603b56998f6b3ee2611/Modules/getpath.c#L802-L837\n\nThe spotty platform support stroke me as odd, especially on macOS, as I see no apparent reason for only supporting framework builds, so I looked traced back the origin of this code.\n\nThe macOS logic goes back to Python 2.0, having been introduced in 54ecc3d24f52ae45ca54a24167e434915c88b60f. At this time, we were determining `base_prefix`/`base_exec_prefix` based on the Python interpreter location, which was problematic on [OS X Frameworks](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html), as the Python interpreter is provided via a launcher. The comment traces back to 55070f5d966f09256c603c3a82fab9b034430c6f and is unrelated to the change made by that commit, it just highlights the special case for macOS framework builds.\n\nIn GH-29041, which introduced `getpath.py`, rewriting the old path initialization C code in Python, the logic changed to purposefully search the `libpython` location before the executable location, also adding Windows support. I imagine the existing macOS code was kept as-is as a mistake, leaving it behind the `WITH_NEXT_FRAMEWORK` flag, maybe under the assumption it was needed for some reason.\n\nConsidering the clear intent in the code, I am treating this a bug.\n\ncc @zooba\n\n### CPython versions tested on:\n\nCPython main branch\n\n### Operating systems tested on:\n\n_No response_\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-127972\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/FFY00","@type":"Person","name":"FFY00"},"datePublished":"2024-12-15T18:19:22.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/127970/cpython/issues/127970"}