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

804 + Improve 'no installers available' messaging #823

Merged
merged 21 commits into from
Feb 20, 2018
Merged

804 + Improve 'no installers available' messaging #823

merged 21 commits into from
Feb 20, 2018

Conversation

MikhailArkhipov
Copy link

Fixes #804 as well as improves 'No installers available' case.

  • Move channel management to a separate class for testability
  • Improved message when no installers found with 'Search for help' option that searches Web for how to install pip on the current platform
  • fixed cases when virtual env interpreter actually was returned as 'unknown'
  • tests

@MikhailArkhipov MikhailArkhipov changed the title Improve detection 804 + Improve 'no installers available' messaging Feb 19, 2018
@codecov
Copy link

codecov bot commented Feb 19, 2018

Codecov Report

Merging #823 into master will increase coverage by <.01%.
The diff coverage is 90.9%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #823      +/-   ##
==========================================
+ Coverage   63.64%   63.64%   +<.01%     
==========================================
  Files         258      260       +2     
  Lines       11807    11837      +30     
  Branches     2088     2093       +5     
==========================================
+ Hits         7514     7534      +20     
- Misses       4285     4295      +10     
  Partials        8        8
Impacted Files Coverage Δ
src/client/interpreter/virtualEnvs/types.ts 100% <ø> (ø) ⬆️
src/client/interpreter/index.ts 62.92% <0%> (-1.45%) ⬇️
...rpreter/locators/services/baseVirtualEnvService.ts 75% <100%> (-0.52%) ⬇️
src/client/interpreter/virtualEnvs/index.ts 100% <100%> (ø) ⬆️
src/client/interpreter/virtualEnvs/virtualEnv.ts 100% <100%> (ø) ⬆️
src/client/interpreter/virtualEnvs/venv.ts 100% <100%> (ø) ⬆️
src/client/common/installer/serviceRegistry.ts 100% <100%> (ø) ⬆️
...nterpreter/locators/services/currentPathService.ts 94.44% <100%> (+0.15%) ⬆️
src/client/common/installer/productNames.ts 100% <100%> (ø)
src/client/common/installer/types.ts 100% <100%> (ø) ⬆️
... and 20 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3fe37a2...55ff4e5. Read the comment docs.

@DonJayamanne
Copy link

@MikhailArkhipov
We need to perform the check after setting the interpreter.

I.e. change this code

  const pythonInstaller = new PythonInstaller(serviceContainer);
    pythonInstaller.checkPythonInstallation(PythonSettings.getInstance())
        .catch(ex => console.error('Python Extension: pythonInstaller.checkPythonInstallation', ex));

    // This must be completed before we can continue.
    await interpreterManager.autoSetInterpreter();

to this:

    // This must be completed before we can continue.
    await interpreterManager.autoSetInterpreter();

  const pythonInstaller = new PythonInstaller(serviceContainer);
    pythonInstaller.checkPythonInstallation(PythonSettings.getInstance())
        .catch(ex => console.error('Python Extension: pythonInstaller.checkPythonInstallation', ex));

});
const displayName = await this.versionProvider.getVersion(interpreter, path.basename(interpreter));
const virtualEnv = await this.virtualEnvMgr.detect(interpreter);
const virtualEnvSuffix = virtualEnv ? virtualEnv.name : this.getVirtualEnvironmentRootDirectory(interpreter);
Copy link

@DonJayamanne DonJayamanne Feb 19, 2018

Choose a reason for hiding this comment

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

The previous approach of Promise.all() would be faster.
This new approach will be pretty much a sequential approach.
First code will wait to get version from getVersion, then after the value is available it will move onto detect.

Where as with Promise.all both methods will be executed and we'll wait for both to complete.

This then affects the overall time taken to discover interpreters.

Copy link
Author

Choose a reason for hiding this comment

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

As far as I understand they are not actually run in parallel but sure. I mean, there is no thread switch in a middle of async code at it happens in C# or C++ threading, so each call executes to the end before another call begins. Hence no thread synchronization primitives AFAIK. Then can execute out or order though.

});
let displayName = await this.versionProvider.getVersion(interpreter, path.basename(interpreter));
const virtualEnv = await this.virtualEnvMgr.detect(interpreter);
displayName += virtualEnv ? ` (${virtualEnv.name})` : '';

Choose a reason for hiding this comment

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

The previous approach of Promise.all() would be faster.
This new approach will be pretty much a sequential approach.
First code will wait to get version from getVersion, then after the value is available it will move onto detect.

Where as with Promise.all both methods will be executed and we'll wait for both to complete.

@@ -16,7 +16,7 @@ export class JediFactory implements Disposable {
this.disposables = [];
}
public getJediProxyHandler<T extends ICommandResult>(resource: Uri): JediProxyHandler<T> {
const workspaceFolder = workspace.getWorkspaceFolder(resource);
const workspaceFolder = resource ? workspace.getWorkspaceFolder(resource) : undefined;

Choose a reason for hiding this comment

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

We should change the signature of the parameter to resource?:Uri to be explicit about the fact that resource can be undefined.

@MikhailArkhipov
Copy link
Author

I have a feeling that interpreterManager.initialize() needs to be called first.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Warning about system python in MacOS but correctly uses virtualenv
2 participants