fix(julia): restore Python executable for JuliaCall 0.9.35

[MilesCranmerBot]

Why

JuliaCall 0.9.35 sets JULIA_PYTHONCALL_EXECUTABLE, but PythonCall reads JULIA_PYTHONCALL_EXE. Julia workers therefore try to create a separate CondaPkg Python environment instead of using the parent interpreter.

Apply the equivalent of the upstream correction in JuliaPy/PythonCall.jl#814 at PySR's existing import boundary.

Scope

• In _import_juliacall, set JULIA_PYTHONCALL_EXE = sys.executable or "" before the import, only for JuliaCall 0.9.35.
• Add a real-worker regression for both import orders. It clears inherited interpreter settings, runs CondaPkg offline, checks interpreter identity, and executes Python on the worker.

Blast Radius

Other JuliaCall versions remain unchanged. Assignment replaces stale interpreter paths, matching the upstream correction. This also configures future workers when JuliaCall was imported first; it cannot repair workers already running. Saved Julia interpreter preferences retain their existing precedence.

Verification

Passed on Linux with Python 3.10, Julia 1.10.11, JuliaCall/PythonCall 0.9.35, and CondaPkg offline:

pysr.test.test_startup.TestStartup.test_juliacall_0935_distributed_worker_uses_current_python
pysr.test.test_type_specs.TestTypeSpecs.test_template_type_spec_parallelism_matrix
pysr.test.test_type_specs.TestTypeSpecs.test_template_type_spec_parameters

All three tests passed in 145.301 seconds. Separate real-runtime probes confirmed stale-interpreter replacement and unchanged behavior for JuliaCall 0.9.34. Both changed files passed black --check. The full suite and conda-build were not rerun.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!