Skip to content

Use python execution service, not general process execution service for non-daemon raw start. #12846

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

Conversation

IanMatthewHuff
Copy link
Member

@IanMatthewHuff IanMatthewHuff commented Jul 9, 2020

For #12821

  • Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
  • Title summarizes what is changing.
  • Has a news entry file (remember to thank yourself!).
  • Appropriate comments and documentation strings in the code.
  • Has sufficient logging.
  • Has telemetry for enhancements.
  • Unit tests & system/integration tests are added/updated.
  • Test plan is updated as appropriate.
  • package-lock.json has been regenerated by running npm install (if dependencies have changed).
  • The wiki is updated with any design decisions/details.

@IanMatthewHuff
Copy link
Member Author

This is why I'm glad we have the validate step. Glad that @rchiodo caught this.

My fix for 2.7 initially did this:

  1. Try to launch the daemon
  2. If the daemon comes back as a IPythonExecutionService then we failed to launch the daemon
  3. Return undefined from the daemon launcher
  4. In the kernel process if the daemon launcher returns undefined, then use process execution service to launch the kernel spec

This would work, and was working for my test case. But it could very easily pick up the wrong interpreter. It would certainly pick the wrong one for anything that was just an interpreter and not an venv / conda env.

New flow is:

  1. Try to launch the daemon
  2. If the daemon comes back as an IPythonExecutionService then use that to launch the process in the daemon launcher
  3. Only use the general process execution service for non-python.

@IanMatthewHuff
Copy link
Member Author

I might check this in first, since I want this fix in release. But maybe we could use a functional test here? I'll look into if it's reasonable to write one.

@rchiodo
Copy link

rchiodo commented Jul 9, 2020

Functional tests (that actually use jupyter) use conda at the moment. I believe you said conda doesn't have this problem.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Jul 9, 2020

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 0 Security Hotspots to review)
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@IanMatthewHuff IanMatthewHuff merged commit 2ce96b0 into microsoft:master Jul 9, 2020
@IanMatthewHuff IanMatthewHuff deleted the dev/ianhu/fixNonDaemonRawLaunch branch July 9, 2020 23:08
IanMatthewHuff added a commit to IanMatthewHuff/vscode-python that referenced this pull request Jul 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants