-
-
Notifications
You must be signed in to change notification settings - Fork 30
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
[FR]: include (de)activation scripts in venvs #344
Comments
They are somewhat intentionally left out, as it adds extra maintenance overhead for each shell that needs its own activation script. "activate" doesn't really do anything apart from put the interpreter first on the PATH, you can call the interpreter directly in the bin folder and it'll do the right thing without needing any "activation". I can see how it could be useful however if other applications expect the just run "python", I'll see how much overhead this really adds. |
I think it would still be useful to have the activation script for users who aren't using VSCode like integrations that handle this automatically. For example if you use vim and you want the env in that editor to point to the generated venv, you'd virtually have to write your own activation script AFAIUI |
👍 To request. For a concrete use case: I use a mixture of VSCode integrations and the VSCode integrated terminal which can auto-activate the current venv. This nicely allows me to use dev tool CLIs without needing to be super careful about python location. So if I'm bazeling with |
What is the current behavior?
I've a repository with multiple python distribution packages. I have this rule at the root of my repo meant to create a venv for use by my IDE:
The venv produced by
rules_py
does not include (de)activation scripts. I'm using version 0.7.3 of the rules.Describe the feature
Add activate/deactivate scripts in the venv as per regular venv creation.
The text was updated successfully, but these errors were encountered: