VirtualEnv in Python doesn't trigger postactivate

[1st]

I've a file with post activate logic located at ~/.virtualenvs/env_name/bin/postactivate that can contain something like this:

export ENV_NAME=local
cd ./src

It works file if I use workon env_name command from Virtual Env Wrapper.

But when I create a new terminal inside VSCode it activate the env like this:
source /Users/anton/.virtualenvs/env_name/bin/activate

And problem here that postactivate script isn't run.

It will be good to use virualenvwrapper inside VS Code or alternatively add extra commands that will be executed after activation of the python virtual env.

If it's already a way how to execute additional script after activation of the virtual env - please let me know. I didn't find such property in VS Code settings file.

Thank you

[karthiknadig]

We don't support workon. At this point this is a feature request.

[karthiknadig]

Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

[1st]

@karthiknadig Maybe you know how to make it possible to execute some script that sets env variables in the new terminal every time when I open a new terminal inside VS Code? Currently it only activates the virtual env, but I want to run an additional shell script that will run some additional logic.

As a way to do this - you can add a post_activate_script option to the settings. Maybe you already have something like this available via settings?

I’ve found that it’s a trigger for “.env” file that is in the project root directory. But it just sets variables. I need also to change a working for to something like “src” inside the root dir. This way every time when I will open a new terminal window it will set all necessary env variables and will switch directory to “src”, as well it will activate the virtual env inside the terminal.

Need your help in solving such situation with the currently available options. And will be good to make a generic approach to simplify this thing for future.

[luabud]

Thanks for the suggestion! We talked about it with the team and we have unfortunately decided we will not be moving forward with this idea. We think there isn't an enough widespread need for this to warrant the maintenance cost for the feature.

As for a workaround, we unfortunately don't have one :( perhaps you could turn off automatic activation of environments and do that process manually?!

FWIW #8870 could provide a workaround for this if we implement it.