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

Implements linting configuration #599

Merged
merged 83 commits into from
Jan 24, 2018
Merged

Implements linting configuration #599

merged 83 commits into from
Jan 24, 2018

Conversation

MikhailArkhipov
Copy link

@MikhailArkhipov MikhailArkhipov commented Jan 18, 2018

Fixes #572

Tests pass, merger with @DonJayamanne TS changes.

  • Implemented 'linter info' for per-linter information
  • Implemented linter manager for various linter-related operations
  • Implemented linter commands
  • Added 'python settings provider' service in order to avoid referencing static classes
  • Split big 'installer' class into multiple for linters, formatters, ctags, frameworks
  • New tests
  • Fixes bunch of missing async/awaits

@codecov
Copy link

codecov bot commented Jan 19, 2018

Codecov Report

Merging #599 into master will decrease coverage by 0.06%.
The diff coverage is 78.67%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #599      +/-   ##
=========================================
- Coverage   60.67%   60.6%   -0.07%     
=========================================
  Files         228     231       +3     
  Lines       10125   10478     +353     
  Branches     1753    1827      +74     
=========================================
+ Hits         6143    6350     +207     
- Misses       3977    4122     +145     
- Partials        5       6       +1
Impacted Files Coverage Δ
src/client/common/types.ts 100% <ø> (ø) ⬆️
...rc/client/common/errors/moduleNotInstalledError.ts 33.33% <0%> (ø) ⬆️
src/client/linters/types.ts 100% <100%> (ø) ⬆️
src/client/common/installer/pipInstaller.ts 87.5% <100%> (+17.12%) ⬆️
src/client/formatters/autoPep8Formatter.ts 95% <100%> (ø) ⬆️
...c/client/linters/errorHandlers/baseErrorHandler.ts 77.77% <100%> (+2.77%) ⬆️
...rc/client/common/process/pythonExecutionFactory.ts 100% <100%> (ø) ⬆️
src/client/common/serviceRegistry.ts 100% <100%> (ø) ⬆️
src/client/linters/pep8.ts 100% <100%> (ø)
src/client/extension.ts 93.95% <100%> (ø) ⬆️
... and 30 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 0253995...36e2fa9. Read the comment docs.

@@ -19,5 +19,6 @@
"python.unitTest.promptToConfigure": false,
"python.workspaceSymbols.enabled": false,
"python.formatting.provider": "none",
"files.insertFinalNewline": true
"files.insertFinalNewline": true,

Choose a reason for hiding this comment

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

👍

@@ -23,6 +23,8 @@
"python.command.jupyter.gotToPreviousCell.title": "Go to Previous Cell",
"python.command.jupyter.gotToNextCell.title": "Go to Next Cell",
"python.command.python.goToPythonObject.title": "Go to Python Object",
"python.command.python.setLinter.title": "Select Linter",
"python.command.python.enableLinting.title": "Enable Linting",

Choose a reason for hiding this comment

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

Can we use this command to disable linting as well?
Three buttons, last being the default VS Code button.
E.g. Enable or disable linting [Enable Linting] [Disable Linting] [Close]

Copy link
Author

Choose a reason for hiding this comment

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

It currently shows on/off list

Choose a reason for hiding this comment

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

👍

export interface IPythonSettingsProvider {
getInstance(resource?: Uri): IPythonSettings;
// tslint:disable-next-line:no-any
updateSettingAsync(setting: string, value: any, resource?: Uri): Promise<void>;

Choose a reason for hiding this comment

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

Please change setting to a strongly typed value, we need to ensure only valid items are being set in here.
Similar to what has been done here https://github.com/Microsoft/vscode-python/blob/master/src/test/common.ts#L20

We also need a configuration target for this. Are we setting in:

  • Global
  • Workspace
  • Workspace folder

Again, please check https://github.com/Microsoft/vscode-python/blob/master/src/test/common.ts#L20.

const deprecationMgr = new FeatureDeprecationManager(persistentStateFactory, !!jupyterExtInstalled);
deprecationMgr.initialize();
context.subscriptions.push(new FeatureDeprecationManager(persistentStateFactory, !!jupyterExtInstalled));
function configureIndentActions(): void {

Choose a reason for hiding this comment

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

Question: Should we move this into a separate folder, languages or formatters?

return settings.linting[this.enabledSettingName] as boolean;
}

public pathName(resource?: Uri): string {

Choose a reason for hiding this comment

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

should this be named getPathName as its a method (verb)

const settings = this.settingsProvider.getInstance(resource);
return settings.linting[this.pathSettingName] as string;
}
public linterArgs(resource?: Uri): string[] {

Choose a reason for hiding this comment

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

should this be named getLinterArgs as its a method (verb)

constructor(private serviceContainer: IServiceContainer, registerCommands: boolean) {
this.linterManager = this.serviceContainer.get<ILinterManager>(ILinterManager);
this.appShell = this.serviceContainer.get<IApplicationShell>(IApplicationShell);
if (registerCommands) {

Choose a reason for hiding this comment

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

FYI - No need to change, but I've introduced a ICommandManager to wrap the vscode.scommands namespace

Copy link
Author

Choose a reason for hiding this comment

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

Changed to CM


private async verifySetting(pythonConfig: WorkspaceConfiguration, target: ConfigurationTarget, settingName: string, value: {}): Promise<void> {
if (isTestExecution()) {
let retries = 0;

Choose a reason for hiding this comment

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

Can't we mock this? I have started moving this settings with the creation of workspacemanager to wrap vscode.wor

Copy link
Author

Choose a reason for hiding this comment

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

This basically for test stability. It guarantees that the setting has actually updated (rather than waiting 5 seconds as in a few other places)

Choose a reason for hiding this comment

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

Agreed, but I'm still reluctant to have this test specific code in the (production code) extension. Can't we move this into just the tests?


await pythonConfig.update(setting, value, settingsInfo.target);
await this.verifySetting(pythonConfig, settingsInfo.target, setting, value);
PythonSettings.dispose();

Choose a reason for hiding this comment

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

Do we need the check verify setting, I am reluctant to have it just for our tests. This should always work in production, hence not necessary, and mocking it should work.

@@ -23,6 +23,8 @@
"python.command.jupyter.gotToPreviousCell.title": "Go to Previous Cell",
"python.command.jupyter.gotToNextCell.title": "Go to Next Cell",
"python.command.python.goToPythonObject.title": "Go to Python Object",
"python.command.python.setLinter.title": "Select Linter",
"python.command.python.enableLinting.title": "Enable Linting",

Choose a reason for hiding this comment

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

👍

if (!PythonSettings.pythonSettings.has(workspaceFolderKey)) {
const settings = new PythonSettings(workspaceFolderUri);
PythonSettings.pythonSettings.set(workspaceFolderKey, settings);
}
// tslint:disable-next-line:no-non-null-assertion
return PythonSettings.pythonSettings.get(workspaceFolderKey)!;
}

public static getSettingsUriAndTarget(resource?: Uri): { uri: Uri | undefined, target: ConfigurationTarget } {
const workspaceFolder = resource ? vscode.workspace.getWorkspaceFolder(resource) : undefined;

Choose a reason for hiding this comment

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

Please use IWorkspaceService instead of the vscode.workspace namespace. You should be able to mock the settings this way and be able to remove test specific code from the extension as well.

Copy link
Author

Choose a reason for hiding this comment

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

Actually, I prefer to use actual objects where possible since they work same way in tests as they do at run time. Mocking is more for something that cannot be instantiated easily for whatever reason (ex project system in big VS) or simulate things that are hard to change (such as registry data - which requires Windows and admin rights).


private async verifySetting(pythonConfig: WorkspaceConfiguration, target: ConfigurationTarget, settingName: string, value?: {}): Promise<void> {
if (isTestExecution()) {
let retries = 0;

Choose a reason for hiding this comment

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

Can we get rid of this, and use the mocked vscode.workspace namespace.
I'm very reluctant to have test specific code in here.

Choose a reason for hiding this comment

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

What I've done in such situations is avoided updating settings, and just using a specific workspace with hardcoded settings in the settings.json file (if you look at the testMultiRootWkspace folder, you can see multiple workspace folders in there, some have settings.json with specific settings in there.

Copy link
Author

Choose a reason for hiding this comment

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

It works at runtime, just not instantly. I observed actual value change in ~500-1000ms (and the config change event to fire). In tests it often ends up reading value that is stale. So it is not necessary to delay action in production but in tests it improves stability.

Choose a reason for hiding this comment

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

So it is not necessary to delay action in production but in tests it improves stability.

If thats the case, why not move this delay into the tests itself. As this block of code never gets used in production, i.e. its test specific?

My only concern about this is the proliferation of if isTetExecution() in our code, just for tests.

Copy link
Author

@MikhailArkhipov MikhailArkhipov Jan 22, 2018

Choose a reason for hiding this comment

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

The problem here is that test would need to know that code it is calling might update the settings. For example, LinterManager.enableLinting and friends - and to know what key to use for ensuring the updated value. Since updating setting is rarely performance-critical (if ever), we can simple get it called in all cases. I'd reduce step to, say, 200ms and have 25 retries. It most cases operation completes in ~500ms so it should not be a big deal anyway.

const pythonSettings = this.configurationService.getSettings(file);

this.setCwdForFileExecution(file);
await this.setCwdForFileExecution(file);

Choose a reason for hiding this comment

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

👍

@MikhailArkhipov MikhailArkhipov merged commit df39217 into microsoft:master Jan 24, 2018
@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.

'Configure Linter' command
2 participants