macOS/uv: venv tests fail (dyld error), not resolved by symlinks=False

[SongChiYoung]

What happened?

Describe the bug

The pytest tests test_local_executor_with_custom_venv and test_local_executor_with_custom_venv_in_local_relative_path located in packages/autogen-ext/tests/code_executors/test_commandline_code_executor.py fail when run on macOS (aarch64) using a Python interpreter managed by uv (following the project's recommended development setup).

The failure occurs during the creation of a nested virtual environment using Python's standard venv.EnvBuilder. Specifically, the attempt to run ensurepip inside the newly created venv fails immediately with a SIGABRT signal. The root cause appears to be a dynamic library loading error (dyld error) where the Python executable inside the newly created venv cannot find its required libpythonX.Y.dylib shared library.

This issue persists even when explicitly setting symlinks=False in venv.EnvBuilder, which should force copying of files instead of symlinking.

To Reproduce

1. Environment Setup:

   • OS: macOS (tested on aarch64 / Apple Silicon)
   • Install uv (following AutoGen's specified version if applicable).
   • Clone the autogen repository.
   • Navigate to the python directory.
   • Create and sync the development environment using uv sync --all-extras. This uses a uv-managed Python interpreter (e.g., cpython-3.11.11-macos-aarch64-none as seen in tracebacks).
   • Activate the virtual environment: source .venv/bin/activate

2. Run Tests:

   • Execute the tests using poe test or directly target the specific file:

     pytest packages/autogen-ext/tests/code_executors/test_commandline_code_executor.py

3. Observe Failure: The tests mentioned above will fail.

4. Traceback: The failure occurs within venv.EnvBuilder.create, specifically when calling _setup_pip -> _call_new_python -> subprocess.check_output (or subprocess.run). The key parts of the traceback are:

   # Condensed Traceback showing the failure point and error
   packages/autogen-ext/tests/code_executors/test_commandline_code_executor.py:175: in test_local_executor_with_custom_venv
    env_builder.create(temp_dir)
   <...>/python3.11/venv/__init__.py:77: in create
    self._setup_pip(context)
   <...>/python3.11/venv/__init__.py:359: in _setup_pip
    self._call_new_python(context, '-m', 'ensurepip', '--upgrade', '--default-pip')
   <...>/python3.11/venv/__init__.py:355: in _call_new_python
    subprocess.check_output(args, **kwargs)
   <...>/python3.11/subprocess.py:466: in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, ...)
   <...>/python3.11/subprocess.py:571: in run
    raise CalledProcessError(retcode, process.args, output=stdout, stderr=stderr)
   
   # Captured stdout from the failing subprocess shows the dyld error:
   # stdout = b"dyld[...]: Library not loaded: @executable_path/../lib/libpython3.11.dylib\n  Referenced from: <...>/python3.11\n  Reason: tried: '[...]/lib/libpython3.11.dylib' (no such file), '/private/var/folders/[...]/lib/libpython3.11.dylib' (no such file)\n"
   
   # The final exception:
   E subprocess.CalledProcessError: Command '['/var/folders/[...]/python3.11', '-m', 'ensurepip', '--upgrade', '--default-pip']' died with <Signals.SIGABRT: 6>.
   

5. Note: Modifying the test code to use venv.EnvBuilder(with_pip=True, symlinks=False) results in the exact same error and traceback.

Expected behavior

The tests test_local_executor_with_custom_venv and test_local_executor_with_custom_venv_in_local_relative_path should pass successfully on macOS when using the recommended uv-based development environment. The standard venv.EnvBuilder should be able to create a functional virtual environment where ensurepip can run, allowing the CommandlineCodeExecutor to utilize custom virtual environments as intended.

Screenshots

N/A (Traceback provides the necessary details)

Additional context

• Root Cause Analysis: The failure stems from the Python executable within the venv created by venv.EnvBuilder being unable to locate its libpythonX.Y.dylib shared library via the relative path (@executable_path/../lib/). This occurs specifically when the base Python interpreter is one managed by uv on macOS. The exact reason why symlinks=False (copying) doesn't resolve this is unclear, but it suggests a deeper incompatibility in how the uv-provided Python is built/structured and how venv expects to create environments from it on macOS.
• Platform Specificity: This issue appears specific to macOS. It's expected that these tests would pass on Linux using a similar uv-based setup due to differences in dynamic linking mechanisms.
• Potential Workarounds Discussed:
  1. Modify Tests to Use uv venv: Change the test implementation to use subprocess to call uv venv --python ... instead of the venv module. This aligns with the project's tooling and works but slightly changes the test's scope.
  2. Skip Tests: Use @pytest.mark.skipif to skip these specific tests on the problematic platform/environment combination (macOS + uv Python). This allows the test suite to pass but avoids testing the functionality.
• Question: Is this considered a bug in the AutoGen test code (for not being compatible with the recommended dev setup on macOS), or does it point to an underlying issue in Python's venv module or the uv-provided Python builds for macOS that needs addressing upstream? How should these tests be handled for developers using the recommended setup on macOS?

Which packages was the bug in?

Python Extensions (autogen-ext)

AutoGen library version.

Python dev (main branch)

Other library version.

No response

Model used

No response

Model provider

None

Other model provider

No response

Python version

3.11

.NET version

None

Operating system

MacOS

[SongChiYoung]

At first, I thought this was just my setup and had been skipping the tests locally. But after digging into it more, I realized it’s not just my environment - so I’m sharing this here in case it helps others.

[withsmilo]

The same issue here. However, I think you can skip this test case on your MacOS environment because it requires to rebuild Python itself to get libpython3.11.dylib.

[SongChiYoung]

@withsmilo Yes, I agree we should skip the test on macOS + uv.
In addition, I think we could add a separate test case that builds a venv using uv directly (without relying on the venv module), to ensure compatibility in that environment.

[SongChiYoung]

@ekzhu
Could I resolve it? with

1. passing MacOS + uv
2. adding venv via uv