Skip to content

Stop using "exec()" in the extension. #7697

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

Closed
5 tasks
ericsnowcurrently opened this issue Sep 30, 2019 · 5 comments
Closed
5 tasks

Stop using "exec()" in the extension. #7697

ericsnowcurrently opened this issue Sep 30, 2019 · 5 comments
Assignees
Labels
area-environments Features relating to handling interpreter environments debt Covers everything internal: CI, testing, refactoring of the codebase, etc.

Comments

@ericsnowcurrently
Copy link

ericsnowcurrently commented Sep 30, 2019

Switch to using PythonExecutionFactory (instead of exec()) in the following places:

  • testing
    • src/client/testing/common/services/discovery.ts
    • src/client/testing/navigation/symbolProvider.ts
  • installers
    • src/client/common/installer/moduleInstaller.ts
    • src/client/common/installer/poetryInstaller.ts
  • [ ] old debug adapter
  • interpreter discovery
    • src/client/interpreter/display/shebangCodeLensProvider.ts
    • src/client/interpreter/interpreterVersion.ts
    • src/client/interpreter/locators/services/condaService.ts
    • src/client/interpreter/locators/services/currentPathService.ts
    • src/client/interpreter/locators/services/pipEnvService.ts
    • src/client/interpreter/virtualEnvs/index.ts
  • import sorting
    • src/client/providers/importSortProvider.ts
  • code execution / terminal
    • src/client/terminals/codeExecution/helper.ts
@ericsnowcurrently ericsnowcurrently added needs PR debt Covers everything internal: CI, testing, refactoring of the codebase, etc. labels Sep 30, 2019
@DonJayamanne DonJayamanne mentioned this issue Oct 9, 2019
24 tasks
@karthiknadig karthiknadig added this to the 2019 October Sprint 2 milestone Oct 9, 2019
@gramster gramster added area-environments Features relating to handling interpreter environments and removed feature-interpreter labels Oct 10, 2019
@karthiknadig karthiknadig self-assigned this Oct 19, 2019
@karthiknadig
Copy link
Member

karthiknadig commented Oct 26, 2019

@ericsnowcurrently what is the motivation for this work item?

This is what i am seeing so far: #8230

  • src/client/testing/common/services/discovery.ts: Looks like it is already using IPythonExecutionService

  • src/client/testing/navigation/symbolProvider.ts: Updated

  • src/client/common/installer/moduleInstaller.ts: Looks like this needs sudo support in IProcessService. Not really a IPythonExecutionService

  • src/client/common/installer/poetryInstaller.ts: This is using poetry path setting. Since that path is to an executable this should not be using IPythonExecutionService

  • src/client/interpreter/display/shebangCodeLensProvider.ts: I see IProcessService.exec() being used here. I see getFullyQualifiedPathToInterpreter, is the idea to replace it with IPythonExecutionService?

  • src/client/interpreter/interpreterVersion.ts: Updated.

  • src/client/interpreter/locators/services/condaService.ts: This is conda specific, in some cases cond has to be activated to directly use python. I don't see why this should use IPythonExecutionService

  • src/client/interpreter/locators/services/currentPathService.ts: Updated. Feels like it should not use that.

  • src/client/interpreter/locators/services/pipEnvService.ts: Updated. Feels like it should not use that.

  • src/client/interpreter/virtualEnvs/index.ts: Uses pyenv not python. So should not use IPythonExecutionService

  • src/client/providers/importSortProvider.ts: Already using IPythonExecutionService when using sortImports.py

  • src/client/terminals/codeExecution/helper.ts: Updated

@DonJayamanne
Copy link

Agreed with karthik, except with interpreter version. Don't update, comments in PR.

@ericsnowcurrently
Copy link
Author

What do you mean by "what is the motivation"? If you mean "why does this issue exist?", I created it to track what files were running Python using exec (or a proxy for it) directly, rather than through the PythonExecutionService. Those places would not be able to take advantage of specializations in PythonExecutionService, including our use of "conda run".

@ericsnowcurrently
Copy link
Author

  • src/client/testing/common/services/discovery.ts: Looks like it is already using IPythonExecutionService

Yep, I missed that.

  • src/client/common/installer/moduleInstaller.ts: Looks like this needs sudo support in IProcessService. Not really a IPythonExecutionService

Shouldn't PythonExecutionService support sudo then? Otherwise we have to duplicate here the specializations we make there, including "conda run" support. Also, our use of sudo should be extrenely limited and possibly removed if possible.

  • src/client/common/installer/poetryInstaller.ts: This is using poetry path setting. Since that path is to an executable this should not be using IPythonExecutionService

Using the poetry path setting is potentially problematic, since it would not necessarily have effect on the currently selected interpreter environment. Also, I expect it does not cooperate well with Anaconda. So this needs more understanding.

  • src/client/interpreter/display/shebangCodeLensProvider.ts: I see IProcessService.exec() being used here. I see getFullyQualifiedPathToInterpreter, is the idea to replace it with IPythonExecutionService?

The main goal is to use PythonExecutionService, one way or the other. :)

  • src/client/interpreter/locators/services/condaService.ts: This is conda specific, in some cases cond has to be activated to directly use python. I don't see why this should use IPythonExecutionService
  • src/client/interpreter/locators/services/currentPathService.ts: Updated. Feels like it should not use that.
  • src/client/interpreter/locators/services/pipEnvService.ts: Updated. Feels like it should not use that.

I think you're right. These are interpreter locators. So they should run indepedently of the currently selected interpreter. That said, there may be more to it than that.

  • src/client/interpreter/virtualEnvs/index.ts: Uses pyenv not python. So should not use IPythonExecutionService

Yeah, I'm pretty sure this is locator code too.

  • src/client/providers/importSortProvider.ts: Already using IPythonExecutionService when using sortImports.py

Yeah, I think you're right.

@kimadeline
Copy link

✅ Validated using 2019.11.47235-dev:

  • src/client/testing/navigation/symbolProvider.ts: navigated to tests from the test explorer view
  • src/client/terminals/codeExecution/helper.ts: executed line in terminal, executed selection in terminal

@ghost ghost removed the needs PR label Nov 7, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Nov 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-environments Features relating to handling interpreter environments debt Covers everything internal: CI, testing, refactoring of the codebase, etc.
Projects
None yet
Development

No branches or pull requests

5 participants