Gazelle failing when executed from within a virtual environment

[psalaberria002]

🐞 bug report

Affected Rule

The issue is caused by the Gazelle Python plugin.

Is this a regression?

Yes, the previous version in which this bug was not present was: 0.26.0

Description

Gazelle (with the Python plugin enabled) crashes when executed from within a virtual environment.

🔬 Minimal Reproduction

A reproduction can be found at https://github.com/psalaberria002/rules_python_gazelle_repro.

$ bazel run //:venv
$ source .venv/bin/activate
$ bazel run //:gazelle

🔥 Exception or Error

$ bazel run gazelle                                                          
INFO: Analyzed target //:gazelle (60 packages loaded, 9983 targets configured).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  bazel-bin/gazelle-runner.bash
  bazel-bin/gazelle
INFO: Elapsed time: 2.561s, Critical Path: 2.34s
INFO: 7 processes: 6 internal, 1 linux-sandbox.
INFO: Build completed successfully, 7 total actions
INFO: Running command line: bazel-bin/gazelle
Could not find platform independent libraries 
Could not find platform dependent libraries 
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'python3'
  isolated = 0
  environment = 1
  user site = 0
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/install/lib/python3.11'
  sys._base_executable = ''
  sys.base_prefix = '/install'
  sys.base_exec_prefix = '/install'
  sys.platlibdir = 'lib'
  sys.executable = ''
  sys.prefix = '/install'
  sys.exec_prefix = '/install'
  sys.path = [
    '/install/lib/python311.zip',
    '/install/lib/python3.11',
    '/install/lib/python3.11/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007faea97d9740 (most recent call first):
  
gazelle: failed to wait for std_modules: exit status 1

🌍 Your Environment

Operating System:

  
Operating System: Pop!_OS 22.04 LTS               
Kernel: Linux 6.4.6-76060406-generic
Architecture: x86-64
  

Output of bazel version:

  
Bazelisk version: v1.12.0
Build label: 7.0.0rc6
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Dec 4 22:34:51 2023 (1701729291)
Build timestamp: 1701729291
Build timestamp as int: 1701729291
  

Rules_python version:

  
0.27.1
  

Anything else relevant?
It started to break in 1.27.0, and 1.27.1 doesn't solve it.

Running Gazelle from outside the venv works as expected.

I have also tried creating the virtual environment with python -m venv .venv to rule out any possible issues
with our rules_pyvenv, but it also fails with the same error.

[aignas]

Just a short message, that I can reproduce the error and I can reproduce it with 3.11.4 and 3.11 toolchains. Not sure yet if this is a problem with how we define toolchains, but for sure it is related to the change in how we include the Python code in gazelle.

[rajukrishnamurthy]

I do not know if this is related, but I bumped rules_python from v0.25.0 to v.0.31.0 but have not investigate where the issue might have need originated. When I specify a package to run gazelle under, it fails with a similar error as above (I'm not running in venv). So, if I run:

bazel run //:gazelle some/package  # works
bazel run //:gazelle some/package  # rerun fails
bazel run //:gazelle some/otherpackage  # works
bazel run //:gazelle some/otherpackage  # rerun fails

if I don't specify a package, I never get a failure.

[aignas]

My hope is that #1929 should help with this issue.

[aignas]

Closing as the latest code is using golang, so should not be affected by Python virtual envs.

[psalaberria002]

Closing as the latest code is using golang, so should not be affected by Python virtual envs.

Has the 'fix' been released? In which version?

[aignas]

It will be in the next release,

…

On 4 June 2024 18:16:45 GMT+09:00, Paul Salaberria ***@***.***> wrote: > Closing as the latest code is using golang, so should not be affected by Python virtual envs. Has the 'fix' been released? In which version? -- Reply to this email directly or view it on GitHub: #1599 (comment) You are receiving this because you modified the open/close state. Message ID: ***@***.***>