[FR]: include (de)activation scripts in venvs

[tnielens]

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:

py_venv(
    name = "venv",
    deps = [ 
        ...
    ]
)

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.

[mattem]

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.

[keith]

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

[bhogan-bdai]

:+1: 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 bazel test and see a failure, I can either click my way through VSCode's testing (with some hotkeys internalized) and set a debugger OR run pytest -k 'name of failing test' --pdb to poke around and find a good first place for the editor debugger.