Incompatible Copy of Pydevd already Imported Error

[KyleMylonakisProtopia]

Encountered an issue this morning with no known meaningful changes to my python environment or vs code version.

~/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/_vendored/force_pydevd.py:18: UserWarning: incompatible copy of pydevd already imported:
~/.conda/envs/llama3/lib/python3.10/site-packages/pydevd_plugins/extensions/pydevd_plugin_omegaconf.py
  warnings.warn(msg + ':\n {}'.format('\n  '.join(_unvendored)))

This warning eventually results in the following errors

Exception ignored in atexit callbackException ignored in atexit callbackUncaught exception in compile_worker subprocess
Traceback (most recent call last):
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/site-packages/torch/_inductor/compile_worker/__main__.py", line 69, in main
    SubprocMain(args.pickler, args.kind, args.workers, read_fd, write_fd).main()
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/site-packages/torch/_inductor/compile_worker/subproc_pool.py", line 267, in __init__
    self.pool = self._new_pool(nprocs, True)
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/site-packages/torch/_inductor/compile_worker/subproc_pool.py", line 278, in _new_pool
    _warm_process_pool(pool, nprocs)
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/site-packages/torch/_inductor/compile_worker/subproc_pool.py", line 366, in _warm_process_pool
    pool._adjust_process_count()
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/concurrent/futures/process.py", line 697, in _adjust_process_count
    self._spawn_process()
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/concurrent/futures/process.py", line 714, in _spawn_process
    p.start()
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/multiprocessing/context.py", line 281, in _Popen
    return Popen(process_obj)
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/home/kyle/.conda/envs/llama3/lib/python3.10/multiprocessing/popen_fork.py", line 66, in _launch
    self.pid = os.fork()
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py", line 965, in new_fork
    _on_forked_process(setup_tracing=apply_arg_patch and not is_subprocess_fork)
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py", line 240, in _on_forked_process
    pydevd.settrace_forked(setup_tracing=setup_tracing)
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/pydevd.py", line 3348, in settrace_forked
    settrace(
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/pydevd.py", line 3020, in settrace
    _locked_settrace(
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/pydevd.py", line 3102, in _locked_settrace
    py_db.connect(host, port)  # Note: connect can raise error.
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/pydevd.py", line 1508, in connect
    s = start_client(host, port)
  File "/home/kyle/.vscode-server/extensions/ms-python.debugpy-2025.8.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py", line 531, in start_client
    s.connect((host, port))
TimeoutError: timed out
: : <function _exit_function at 0x7f01d91c9d80><function _exit_function at 0x7f01d91c9d80>

I am in a remote development environment, with the following versions of software.
VS Code:
Version: 1.100.3 (Universal)
Commit: 258e40fedc6cb8edf399a463ce3a9d32e7e1f6f3
Date: 2025-06-02T13:30:54.273Z
Electron: 34.5.1
ElectronBuildId: 11369351
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Python 3.10.18
ms-python.debugpy version 2025.8.0

Needless to say this is preventing me from being able to work.
Any recommendations on fixes or workarounds?

[rchiodo]

The code that's issuing that warning is checking if 'pydevd' is in the list of modules already imported. You must have pydevd or debugpy already in your python environment somewhere and something else is importing it.

[rchiodo]

Oh yeah the warning tells you the path:

~/.conda/envs/llama3/lib/python3.10/site-packages/pydevd_plugins/extensions/pydevd_plugin_omegaconf.py

You have that installed and it's being pulled in by something else.

[omry]

Thanks @rchiodo.

I’m the author of OmegaConf. We ship a small pydevd plugin for OmegaConf objects, and historically this worked well. It is not only about nicer display in the debugger: the plugin also handles OmegaConf-specific behaviors such as interpolation and missing values, which otherwise can make inspection misleading or even cause inspection itself to fail.

Given the current incompatibility, what would you consider the right way to support this kind of integration in VS Code/debugpy going forward? If a library needs custom debugger behavior to safely inspect its own objects, is there a supported extension point for that, or is the expectation that this sort of support should be contributed upstream to debugpy/pydevd?

I’d appreciate any guidance on the intended path here.

[KyleMylonakisProtopia]

Thanks @rchiodo.

I’m the author of OmegaConf. We ship a small pydevd plugin for OmegaConf objects, and historically this worked well. It is not only about nicer display in the debugger: the plugin also handles OmegaConf-specific behaviors such as interpolation and missing values, which otherwise can make inspection misleading or even cause inspection itself to fail.

Given the current incompatibility, what would you consider the right way to support this kind of integration in VS Code/debugpy going forward? If a library needs custom debugger behavior to safely inspect its own objects, is there a supported extension point for that, or is the expectation that this sort of support should be contributed upstream to debugpy/pydevd?

I’d appreciate any guidance on the intended path here.

Thanks for commenting on this! Just to be clear, I don't like deleting the file still deal with this incompatibility issue, so figuring out a way forward here is still important to me.

[rchiodo]

I believe the incompatibility here was that pydevd in the plugin didn't match. I'm not sure why it wouldn't work if was just referencing the correct pydevd. I assume the pydevd it was referencing was installed in the site-packages folder which is not the same version that the debugger is using.

[omry]

I’m trying to understand what debugpy is defending against here:
https://github.com/microsoft/debugpy/blob/main/src/debugpy/_vendored/force_pydevd.py#L11-L18

My understanding is that this warning is emitted when debugpy finds pydevd-related modules already present in sys.modules before it forces its vendored copy. In my case, the reported module appears to be OmegaConf’s pydevd plugin:
https://github.com/omry/omegaconf/blob/master/pydevd_plugins/extensions/pydevd_plugin_omegaconf.py

That plugin is very small and only imports pydevd extension APIs. OmegaConf does not import it during normal operation, so if it was already loaded, I assume it was imported by an earlier pydevd plugin-discovery step or by another pydevd installation in the environment.

What I’m trying to clarify is:

• Are pydevd plugins generally unsupported or discouraged with debugpy / VS Code?
• Or is the real problem specifically that the plugin may have been imported against a different pydevd installation from site-packages, rather than against debugpy’s vendored copy?

I can work around this on the OmegaConf side by moving the plugin into a separate optional package, but I’d still appreciate clarification on whether pydevd plugins are expected to work in this setup, or whether debugpy intentionally treats any pre-imported pydevd plugin as unsupported.

[rchiodo]

Are pydevd plugins generally unsupported or discouraged with debugpy / VS Code?

They are supported as much anything else in pydevd. We ship a bunch of them. Adding another one should work fine. The API hasn't changed very much so that shouldn't be a problem.

Or is the real problem specifically that the plugin may have been imported against a different pydevd installation from site-packages, rather than against debugpy’s vendored copy?

This is the real problem. Pydevd and the copy in debugpy have diverged somewhat, so loading pydevd from site-packages may break other stuff and we don't support this scenario. It has to use the same vendored Pydevd that comes from Debugpy.

[omry]

This is the real problem. Pydevd and the copy in debugpy have diverged somewhat, so loading pydevd from site-packages may break other stuff and we don't support this scenario. It has to use the same vendored Pydevd that comes from Debugpy.

I don’t think there is anything a third-party package can do to prevent its plugin from being imported once it is installed under site-packages/pydevd_plugins.

Also, instead of warning that some plugin modules were imported, maybe debugpy could try to detect the other pydevd installation on the path and report that directly.