Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the interaction of virtualenv with Python interpreter autodetection #4080

Closed
ben-ng opened this issue Nov 13, 2017 · 4 comments
Closed
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Documentation Documentation improvements that cannot be directly linked to other team labels team-Rules-Python Native rules for Python type: documentation (cleanup)

Comments

@ben-ng
Copy link

ben-ng commented Nov 13, 2017

Description of the problem / feature request / question:

If the bazel server is started when a python virtualenv is activated, actions are run in that virtualenv until the server restarts. bazel clean does not clear this state.

If possible, provide a minimal example to reproduce the problem:

  1. Create a python virtualenv
  2. Create a python script that imports a dependency in that virtualenv
  3. Activate the virtualenv
  4. Build & run the script with bazel. It should exit normally.
  5. Deactivate the virtualenv. Build & run the script with bazel again. It passes, unexpectedly.
  6. bazel shutdown (in practice this happens automatically, which is even more surprising)
  7. Build & run the script with bazel. It now fails because the dependency couldn't be found.

It looks like it's because activating the virtualenv changes PATH, and the deactivation of the virtualenv doesn't propagate to the bazel server.

Environment info

  • Operating System:

CentOS Linux release 7.0.1406

  • Bazel version (output of bazel info release):

release 0.7.0

@vladmos vladmos added category: rules > python P2 We'll consider working on this in future. (Assignee optional) type: bug labels Nov 20, 2017
@brandjon
Copy link
Member

Correct me if I'm wrong, but this seems like a natural consequence of how virtualenv works by manipulating the shell env. I suppose we could have the Bazel CLI client check the current shell environment and compare it with the server's state...

I'd consider this a feature request but we can certainly document this behavior regardless.

@brandjon brandjon added type: feature request type: documentation (cleanup) P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Python Native rules for Python and removed P2 We'll consider working on this in future. (Assignee optional) category: rules > python type: bug labels Oct 19, 2018
@brandjon
Copy link
Member

FWIW, this issue can be avoided by specifying a py_runtime to refer to an interpreter by a fixed absolute path instead of relying on a command lookup in PATH. This will be more mainstream when #7375 is implemented, though it sounds like the default toolchain (which will look up a runtime from PATH) will still be affected by this issue.

@brandjon brandjon changed the title Virtualenv state is stuck in the server Document the interaction of virtualenv with Python interpreter autodetection Mar 14, 2019
@lberki lberki added P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) and removed P3 We're not considering working on this, but happy to review a PR. (No assignee) labels Nov 18, 2020
@sgowroji sgowroji added the team-Documentation Documentation improvements that cannot be directly linked to other team labels label Jan 11, 2023
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Mar 17, 2024
Copy link

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Documentation Documentation improvements that cannot be directly linked to other team labels team-Rules-Python Native rules for Python type: documentation (cleanup)
Projects
None yet
Development

No branches or pull requests

5 participants