Refactor: Move setupPythonSearchPath to its own file

[hoodmane]

This function is long enough that I think it's more readable without having the code inline in python.ts

[ask-bonk]

Now let me carefully analyze the changes for any issues:

1. loadPythonMod in util.ts -- The moduleName is interpolated into a Python string with '${moduleName}'. All callers pass string literals ('setup_python_search_path', 'introspection'), so no injection concern in practice. However, if a future caller passed a name with a single quote, it would break/inject. This is internal-only code though, so this is low-priority.

2. Cleanup concern -- In the old code, setup.destroy() destroyed the callable. In the new code, mod.destroy() destroys the module. But mod.setup_python_search_path (the callable attribute) is not explicitly destroyed. Let me check whether the introspection module has the same pattern:

Looking at the introspection usage in python-entrypoint-helper.ts, the IntrospectionMod is stored long-term and never destroyed -- its methods are called repeatedly. So there's no inconsistency there.

For setupPythonSearchPath, the old code destroyed just the callable. The new code destroys the module. Destroying the module should release the module and all its attributes, so this seems correct -- but let me verify there's no leak of the callable reference.

Looking at python.ts:96-100:

mod.setup_python_search_path.callKwargs({...});
mod.destroy();

The mod.setup_python_search_path is accessed as a property, used inline, and never stored. mod.destroy() destroys the module proxy. This should be fine -- the callable is a sub-reference of the module, and destroying the module should handle it.

3. Behavioral change in python-entrypoint-helper.ts: The old code used await import('pyodide-internal:introspection.py') (dynamic import), and the new code uses a static import import { default as introspectionSource } from 'pyodide-internal:introspection.py'. This changes the module from being lazily loaded to eagerly loaded at module parse time. This is a minor behavioral shift but shouldn't matter since the module is always needed anyway.

4. getIntrospectionMod was previously async because of the dynamic import, and it remains async because of getPyodide() -- this is correct.

Overall this is a clean refactor. The Python logic is identical (same code moved to a .py file), the loadPythonMod utility correctly deduplicates the module-loading boilerplate, the types are declared properly, and the BUILD system picks up the new .py file via glob.

LGTM

github run

[dom96]

Looks good, but see question below.