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

Use Python Extension's getExecutionDetails to get virtualenv information in terminals #200

Closed
rogermparent opened this issue Mar 23, 2021 · 1 comment · Fixed by #201
Closed
Assignees
Labels
discussion enhancement New feature or request

Comments

@rogermparent
Copy link
Contributor

We just found an API that allows us to use the Python extension's virtualenv functionality in any Terminal, not just the standard "black box" Integrated Terminal that we can't read from!

If this works out, we'll be able to make internal DvcReader commands use the virtualenv dvc with no work locating it on our end, and we'll also have the choice to change IntegratedTerminal into any kind of terminal we want, like a Psuedoterminal or even a reader style exec_process call.

While possible a little out of scope for this ticket, we'll probably want to use something like an async queue to work around DVC's lockfile, though we'll also have to check for the presence of an external lock at the start and maybe in between executions.

@mattseddon
Copy link
Member

Here are some open python extension issues that we should be aware of:

  1. Fix onDidChangeExecutionDetails API to fire taking auto selected interpreter in account microsoft/vscode-python#15467
  2. Add getEnvironmentVariables and onDidEnvironmentVariablesChange to IExtensionApi microsoft/vscode-python#15112

and here are two closed issues:

  1. Provide the prefix of a possibly activated conda environment in getExecutionDetails API microsoft/vscode-python#13044
  2. Change public API for execution to return an object and provide a callback which is called when interpreter setting changes microsoft/vscode-python#12596

As shown in this comment on #201 the current approach will not give us what we need to run commands via the cli that require a virtual environment to be activated.

We could patch this behaviour by using the directory that the python interpreter is stored in, stripping off python, inserting activate (activate.exe on Windows) and using this to source the environment at the beginning of each command - i.e /full/path/demo/.env/bin/python -> source /full/path/demo/.env/bin/activate. This will definitely work for virtual environments.

However, if you look at the number of different environment types that the python extension supports I think it would be a good idea to raise an issue in the repository to ask for the environment activation details to be passed out via the public API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants