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

Fix interpreter tests #7410

Merged
merged 49 commits into from
Sep 7, 2021
Merged

Fix interpreter tests #7410

merged 49 commits into from
Sep 7, 2021

Conversation

DonJayamanne
Copy link
Contributor

@DonJayamanne DonJayamanne commented Sep 3, 2021

For #7403

Looks like we have two interpreter paths that end up pointing to the exact same interpreter:

  • /opt/hostedtoolcache/Python/3.8.11/x64/python
  • /opt/hostedtoolcache/Python/3.8.11/x64/bin/python

This PR ensures we have a common way to compare interpreter paths and normalize them so that they are treated the same.

@DonJayamanne DonJayamanne requested a review from a team as a code owner September 3, 2021 14:29
@codecov-commenter
Copy link

codecov-commenter commented Sep 3, 2021

Codecov Report

Merging #7410 (34295a2) into main (cce419f) will decrease coverage by 0%.
The diff coverage is 81%.

❗ Current head 34295a2 differs from pull request most recent head 3429ffc. Consider uploading reports for the commit 3429ffc to get more accurate results

@@          Coverage Diff          @@
##            main   #7410   +/-   ##
=====================================
- Coverage     62%     62%   -1%     
=====================================
  Files        361     361           
  Lines      22563   22623   +60     
  Branches    3416    3435   +19     
=====================================
+ Hits       14141   14147    +6     
- Misses      7223    7264   +41     
- Partials    1199    1212   +13     
Impacted Files Coverage Δ
...ient/datascience/export/exportInterpreterFinder.ts 70% <ø> (ø)
...e/jupyter/interpreter/jupyterInterpreterService.ts 89% <ø> (ø)
src/client/datascience/jupyter/kernels/helpers.ts 69% <75%> (+<1%) ⬆️
src/client/api/pythonApi.ts 60% <83%> (-3%) ⬇️
.../localPythonAndRelatedNonPythonKernelSpecFinder.ts 79% <100%> (+<1%) ⬆️
src/client/pythonEnvironments/info/interpreter.ts 85% <100%> (+7%) ⬆️
...ence/notebook/noPythonKernelsNotebookController.ts 14% <0%> (-26%) ⬇️
src/client/logging/logger.ts 54% <0%> (-16%) ⬇️
...ient/datascience/kernel-launcher/kernelLauncher.ts 84% <0%> (-8%) ⬇️
src/client/logging/transports.ts 76% <0%> (-5%) ⬇️
... and 9 more

@DonJayamanne DonJayamanne force-pushed the issueFixInterpreterTest branch from 805a57d to 4f9c76b Compare September 3, 2021 15:12
@DonJayamanne DonJayamanne force-pushed the issueFixInterpreterTest branch from 4f9c76b to 3d0e80b Compare September 3, 2021 15:43
@@ -21,13 +21,17 @@ runs:

python -m venv .venvkernel
source .venvkernel/bin/activate
python --version
python -c "import sys;print(sys.executable)"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Useful, this is how i figured some of the paths were different.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No harm in leaving this.

) {
return;
}
interpreterCacheForCI.set(resource?.toString() || '', itemToStore);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like Python extension stuff doesn't get logged, this was crucial to figuring out what was going on.
I've enabled this just for CI.
We can remove this, i'm not fussed. I thought it would be useful

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've used the logs from Python extension a lot in the past, hence feel this is useful, but NOT necessary.

Can remove if anyone things we don't need this,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't see an issue with leaving it in myself.

@@ -451,6 +461,10 @@ export function findPreferredKernel(
let subScore = 0;

if (spec) {
traceInfoIf(isCI, `Checking kernel Spec ${JSON.stringify(spec)}`);
traceInfoIf(isCI, `isPythonKernelSpec(spec) = ${isPythonKernelSpec(spec)}`);
traceInfoIf(isCI, `isKernelRegisteredByUs(spec) = ${isKernelRegisteredByUs(spec)}`);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More logging just for CI, found that if the version numbers were 3.8.10 and 3.8.11, we'd end up returuning 3.8.10 as the correct one when 3.8.11 is whats exected.
Hence this logging was very useful.

Again, this only gets logged in CI

score += 4;
}
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved this code down to where we compare major versions (keep both together)

metadata.interpreter?.version?.raw &&
metadata.interpreter?.version?.raw === preferredInterpreter?.version?.raw
) {
traceInfoIf(isCI, 'Increased score by +3 for matching raw version in preferred interpreter');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cam across a scenario where 3.8.10 was picked over 3.8.11 (beacuse both have 3 and 3.8.10 was on the top of the list hence that got picked when both had the same score).

* They are both the same.
* This function will take that into account.
*/
export function areInterpreterPathsSame(path1: string = '', path2:string = '', ostype = getOSType(), fs?: IFileSystem){
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added new helpers to compare paths, ensured the hash also takes this into account.

export async function disableExperimentsInPythonExtension(): Promise<void> {
const vscode = require('vscode') as typeof import('vscode');
const pythonConfig = vscode.workspace.getConfiguration('python', (null as any) as Uri);
await pythonConfig.update('experiments.enabled', false, ConfigurationTarget.Global);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should fix the regressions in Python extension.

}
/**
* Sometimes on CI, we have paths such as (this could happen on user machines as well)
* - /opt/hostedtoolcache/Python/3.8.11/x64/python
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why these are the same? They're the same on your machine, but why everywhere this pattern is found? I would assume on the CI machine these paths are symlinked to each other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same? They're the same on your machine, but why everywhere this pattern is found? I would assume on the CI machine these paths are symlinked to each other?

Yes, if its /bin/xyz and you have xyz then they are the same. I.e. python doesn't hvae multiple different interpreter executables in the same directory. They have python3.5.exe and python.exe` in the same directory and both are the same.

& /bin/ is only used on linux, on windows its always scripts/....
Also we're looking at python file names, hence windows will always be excluded as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

found? I would assume on the CI machine these paths are symlinked to each other?

I think so, i didn't try to figure that out. This is very new, we didn't see this in the past.
Looking back at older runs i couldn't find this. Either ther'es a change in some python package or CI or the python extension is not finding these symlinked items.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'm just nervous this will break something that used to work.

Somebody has say

~/mystuff/python
~/mystuff/bin/python

And those aren't the same. I think you're saying this isn't normal. You wouldn't have bin/python and python at the same level.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ou wouldn't have bin/python and python at the same level.

Yes.
Because if mystuff/python is the python environment, then you won't have a different version interpreter under mystuff/bin/python (thats very very unlikely, from what i know, python doesn't setup interpreters that way).

@DonJayamanne DonJayamanne merged commit f08a71f into main Sep 7, 2021
@DonJayamanne DonJayamanne deleted the issueFixInterpreterTest branch September 7, 2021 20:50
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.

5 participants