[Bug]: Cursor IDE fails to recognize venv

[ambyld]

What happened?

On 1.6.0 with Cursor (0.47.5) and the normal Python extension (2024.12.3), when I try to point my IDE to a generated venv, it fails to recognize the venv and use the associated Python interpreter due to this error:

2025-06-11 21:23:30.117 [info] > ./.examples+py_venv+venv/bin/python -I ~/.cursor/extensions/ms-python.python-2024.12.3-linux-x64/python_files/get_output_via_markers.py ~/.cursor/extensions/ms-python.python-2024.12.3-linux-x64/python_files/interpreterInfo.py
2025-06-11 21:23:30.120 [error] [Error: Command failed: /home/ambyld/Workspace/rules_py/.examples+py_venv+venv/bin/python -I /home/ambyld/.cursor/extensions/ms-python.python-2024.12.3-linux-x64/python_files/get_output_via_markers.py /home/ambyld/.cursor/extensions/ms-python.python-2024.12.3-linux-x64/python_files/interpreterInfo.py
Error:   × $VIRTUAL_ENV was unbound! A venv must be activated
  ╰─▶ environment variable not found
  help: The activate script should be available as "/home/ambyld/.cache/
        bazel/_bazel_ambyld/5f6624201d25ed052fce55277d2ae465/execroot/
        aspect_rules_py/bazel-out/k8-fastbuild/bin/examples/py_venv/.venv/
        bin/activate"

This is working fine on 1.4.0. Perhaps related to the issue #590 was addressing?

Version

Development (host) and target OS/architectures:

Output of bazel --version:

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

Language(s) and/or frameworks involved:

How to reproduce

Any other information?

No response

[alexeagle]

1.6.0 is very new so it's possible we didn't test for this

[arrdem]

This is an artifact of Cursor not executing the bin/activate script and preserving the resulting environment as a real shell would. Not really a bug on our end except inasmuch as we're forced to rely on the venv activation machinery to mitigate sandbox escapes.

There may be more artful solutions to dealing with runfiles sandbox escapes which would be more legible to Cursor and other tooling, which would involve moving bootstrapping logic out of activate and into our interpreter shim.

Somewhat related to #595, the implication of which being that users want to build truly "normal" development virtualenvs which are effectively detatched from Bazel and fundamentally mutable rather than wanting strong guarantees about being in precisely the configuration of a hermetic binary.

[mattnworb]

fwiw this isn't specific to Cursor but is from VS Code in general

[arrdem]

Dropping this here, since there's a couple other related forms of this that have come up.

I think we want to revisit the activate script and the launcher so that rather than using the activate script we add an interpreter_real or something key to the pyvenv.cfg file so that we don't need the runfiles machinery. If the launcher was able to self-configure using only pyvenv.cfg then it'd work better in scenarios like this where people want to consume the interpreter without context.

Effort level is pretty manageable but risk is fairly high just because of the sandbox-related relative path issues we've had so far.

[obs-gh-peterkolloch]

I think that the generated pyvenv.cfg is incorrect.

Mine looks like this with rules version 1.6.1:

home = ./bin/python3
implementation = CPython
version_info = 3.12.0
# FIXME: Can we flip this to false?
# In the case of a virtualenv with .runfiles-packaged Python this needs to be true
# And in the case of a leaked/external interpreter this still needs to be true...
include-system-site-packages = true
relocatable = true

If you compare that with the one that poetry generates:

home = /home/dev/.cache/bazel/_bazel_dev/1b77faf5744799153bb37cbc3b21f32b/execroot/_main/bazel-out/k8-fastbuild/bin/REDACTED/poetry.runfiles/rules_python++python+python_3_12_x86_64-unknown-linux-gnu/bin
implementation = CPython
version_info = 3.12.9.final.0
virtualenv = 20.32.0
include-system-site-packages = false
base-prefix = /home/dev/.cache/bazel/_bazel_dev/1b77faf5744799153bb37cbc3b21f32b/external/rules_python++python+python_3_12_x86_64-unknown-linux-gnu
base-exec-prefix = /home/dev/.cache/bazel/_bazel_dev/1b77faf5744799153bb37cbc3b21f32b/external/rules_python++python+python_3_12_x86_64-unknown-linux-gnu
base-executable = /home/dev/.cache/bazel/_bazel_dev/1b77faf5744799153bb37cbc3b21f32b/external/rules_python++python+python_3_12_x86_64-unknown-linux-gnu/bin/python3.12
prompt = REDACTED-py3.12

You'll see that home doesn't refer to the python binary but the bin directory and it sets a lot more additional paths.

That is in line with the errors that I see in the "Python Language Server" Output in VS Code:

2025-07-31 09:05:21.158 [error] Could not find platform dependent libraries <exec_prefix>
2025-07-31 09:05:21.158 [error] Python path configuration:
2025-07-31 09:05:21.158 [error]   PYTHONHOME = (not set)
2025-07-31 09:05:21.158 [error]   PYTHONPATH = (not set)
2025-07-31 09:05:21.158 [error]   program name = '/home/dev/observe/.REDACTED+venv/bin/python'
2025-07-31 09:05:21.158 [error]   isolated = 1
2025-07-31 09:05:21.158 [error]   environment = 0
2025-07-31 09:05:21.158 [error]   user site = 0
2025-07-31 09:05:21.158 [error]   safe_path = 1
2025-07-31 09:05:21.158 [error]   import site = 1
2025-07-31 09:05:21.158 [error]   is in build tree = 0
2025-07-31 09:05:21.158 [error]   stdlib dir = '/install/lib/python3.12'
2025-07-31 09:05:21.158 [error]   sys._base_executable = '/home/dev/observe/.REDACTED+venv/bin/python'
2025-07-31 09:05:21.158 [error]   sys.base_prefix = '/install'
2025-07-31 09:05:21.158 [error]   sys.base_exec_prefix = '/install'
2025-07-31 09:05:21.158 [error]   sys.platlibdir = 'lib'
2025-07-31 09:05:21.158 [error]   sys.executable = '/home/dev/observe/.REDACTED+venv/bin/python'
2025-07-31 09:05:21.158 [error]   sys.prefix = '/install'
2025-07-31 09:05:21.158 [error]   sys.exec_prefix = '/install'
2025-07-31 09:05:21.158 [error]   sys.path = [
2025-07-31 09:05:21.158 [error]     '/install/lib/python312.zip',
2025-07-31 09:05:21.158 [error]     '/install/lib/python3.12',
2025-07-31 09:05:21.158 [error]     '/install/lib/python3.12/lib-dynload',
2025-07-31 09:05:21.158 [error]   ]
2025-07-31 09:05:21.158 [error] Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
2025-07-31 09:05:21.158 [error] Python runtime state: core initialized
2025-07-31 09:05:21.158 [error] ModuleNotFoundError: No module named 'encodings'```

[obs-gh-peterkolloch]

I tried locally if just adding appropriate relative paths to pyvenv.cfg would fix the problem -- it didn't work. So it is not the whole story and/or we need different or absolute paths there.

This is what I tried:

home = ./bin
implementation = CPython
version_info = {}.{}.{}
# FIXME: Can we flip this to false?
# In the case of a virtualenv with .runfiles-packaged Python this needs to be true
# And in the case of a leaked/external interpreter this still needs to be true...
include-system-site-packages = true
relocatable = true

base-prefix = .
base-exec-prefix = .
base-executable = ./bin/python