-
Notifications
You must be signed in to change notification settings - Fork 294
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
Fix interpreter tests #7410
Conversation
Codecov Report
@@ 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
|
805a57d
to
4f9c76b
Compare
4f9c76b
to
3d0e80b
Compare
@@ -21,13 +21,17 @@ runs: | |||
|
|||
python -m venv .venvkernel | |||
source .venvkernel/bin/activate | |||
python --version | |||
python -c "import sys;print(sys.executable)" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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,
There was a problem hiding this comment.
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)}`); |
There was a problem hiding this comment.
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; | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
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){ |
There was a problem hiding this comment.
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.
src/test/common.ts
Outdated
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); |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
For #7403
Looks like we have two interpreter paths that end up pointing to the exact same interpreter:
This PR ensures we have a common way to compare interpreter paths and normalize them so that they are treated the same.