-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Don't require a system-installed Python interpreter for bootstrapping #8446
Comments
/cc @laszlocsomor |
Can you write up a proposal for goals and rough ideas? |
Just a though about the python (or a future native) wrapper: it would be much nicer if bazel run/test would invoke the correct interpreter directly, passing PYTHONPATH as an env var instead of using execv to replace the wrapper process. I would like to be able to easily wrap --run_under=... to run tools like cProfile or pdb without having to hack wrapper scripts to inject them. |
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 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team ( |
This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team ( |
Forked from discussion in #7947. On windows, we can have the native launcher take on the responsibilities of the stub script, in particular extracting the runfiles. This means it can use any Python runtime to launch the user code, including a runtime in runfiles.
We should also consider creating a native launcher for non-Windows platforms to do the same, so we don't need the
#!/usr/bin/env python
shebang.Finally, we can consider merging the zip file into the launch to create a self-extracting native executable.
The text was updated successfully, but these errors were encountered: