Ignore the language server if the platform is not supported.#2351
Conversation
| } | ||
|
|
||
| // XXX Drop the following (in favor of osType). | ||
| public get isWindows(): boolean { |
There was a problem hiding this comment.
I'll do it in a separate PR.
| } | ||
| public get isMac(): boolean { | ||
| return this._isMac; | ||
| public get osType(): OSType { |
There was a problem hiding this comment.
Why not just os() instead of osType?
| x64 = 3 | ||
| } | ||
| export enum OSType { | ||
| Unsupported, |
There was a problem hiding this comment.
Unknown is better. This could be used on other contexts too.
|
|
||
| let distro = ''; | ||
| let version = ''; | ||
| const data = fs.readFileSync(filename, 'utf-8'); |
There was a problem hiding this comment.
Please use IFileSystem
The logic in this class needs to be testable.
There was a problem hiding this comment.
fixed (wasn't trivial)
| } | ||
| } | ||
|
|
||
| function linux_info_from_file(filename: string = LINUX_INFO_FILE): LinuxInfo { |
There was a problem hiding this comment.
Functions are verbs, hence should be named as such. That's how it is in js and .net world.
Please change to get Linux....
Also please do not use underscores in method names. User Pascal casing.
There was a problem hiding this comment.
E.g. a better name would be getLinuxInformationFromFile
Try avoiding abbreviations.
Codecov Report
@@ Coverage Diff @@
## master #2351 +/- ##
==========================================
+ Coverage 75.38% 75.61% +0.22%
==========================================
Files 309 310 +1
Lines 14331 14506 +175
Branches 2537 2567 +30
==========================================
+ Hits 10804 10969 +165
- Misses 3518 3529 +11
+ Partials 9 8 -1
Continue to review full report at Codecov.
|
| const osType: OSType = values[0]; | ||
| const osVer: string = values[1]; | ||
| const engine: string = values[2]; | ||
| test(`LS is ${engine === 'ls' ? '' : 'not '}supported (${osType} ${osVer})`, async () => { |
There was a problem hiding this comment.
Or you can:
const [osType, osVer, engine] = values
I'm certain that feel a little bit more pythonic too
(Please don't change, it's merely a suggestion).
| const jedi = this.useJedi(); | ||
| let jedi = this.useJedi(); | ||
| if (!jedi && !isLSSupported(this.serviceContainer)) { | ||
| this.appShell.showWarningMessage('The Python Language Server is not supported on your platform.'); |
There was a problem hiding this comment.
Might be worth opening https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1-supported-os.md
There was a problem hiding this comment.
Actually, it would be error. OR we should tell user that we are switching to Jedi explicitly.
|
|
||
| const jediEnabledSetting: keyof IPythonSettings = 'jediEnabled'; | ||
| const LS_MIN_OS_VERSIONS: Map<OSType, string> = new Map([ | ||
| [OSType.OSX, '10.12.0'] // Sierra or higher |
There was a problem hiding this comment.
On MacOS you can simply check os.release() which gives you Darwin version and .NET supports Darwin 16+ (10.12+)
| const platform = services.get<IPlatformService>(IPlatformService); | ||
| const minVer = LS_MIN_OS_VERSIONS[platform.osType]; | ||
| if (minVer === undefined || minVer === null) { | ||
| return true; |
There was a problem hiding this comment.
Show something in the output that platform was not recognized? Or log telemetry?
| const jedi = this.useJedi(); | ||
| let jedi = this.useJedi(); | ||
| if (!jedi && !isLSSupported(this.serviceContainer)) { | ||
| this.appShell.showWarningMessage('The Python Language Server is not supported on your platform.'); |
There was a problem hiding this comment.
This also needs telemetry so we know how many platforms were not supported.
| activator.verifyAll(); | ||
| }); | ||
| }; | ||
| test('Activatory must be activated', async () => { |
There was a problem hiding this comment.
No idea. That was already there.
a837ae2 to
cbb3d2d
Compare
There was a problem hiding this comment.
Please remove stubs file, we should use what we have or other libraries, also we need to be consistent in how we do things (writing tests, coding styles, etc).
Makes it easier for others as well, including those trying to contribute, use standard/popular libraries unless there's a very good reason not to.
| * @memberof FileSystem | ||
| */ | ||
| public readFileSync(filePath: string): string { | ||
| return fs.readFileSync(filePath, 'utf8'); |
There was a problem hiding this comment.
Please remove sync version of file io. Where possible we must use async code.
| @inject(IFileSystem) filesystem?: IFileSystem | ||
| ) { | ||
| if (info) { | ||
| this.os = info; |
There was a problem hiding this comment.
We have three ways to populate the os property, why is this? Why do we need to pass it as an argument? Why can't we always determine it using osinfo.
It's complicated and wrong (encapsulation) to have three ways to do the exact same thing!
We have more code paths to test as well.
There was a problem hiding this comment.
It's not upto the calling classes to provide the is information. Completely defeats the purpose of having this class. This class should be responsible to determine/extract the os information.
Please fix this before merging.
|
|
||
| export function getOSInfo( | ||
| readFile: (string) => string = (filename) => { | ||
| return fs.readFileSync(filename, 'utf8'); |
There was a problem hiding this comment.
This function is not testable due to the use of fs!
You'll need to ensure you have physical files, makes it more difficult to test, these fall into system tests, which is unnecessary for such a simple function.
There was a problem hiding this comment.
I'm not sure I understand. In tests you pass in readFile. fs is only used as the default.
| } | ||
|
|
||
| export class OSInfo { | ||
| constructor( |
There was a problem hiding this comment.
types.js should only contain interfaces/contracts, not implementations.
Please remove the classes from here.
Please fix this before merging
| return new OSInfo(osType, arch, version); | ||
| } | ||
|
|
||
| // Inspired in part by: https://github.com/juju/os |
There was a problem hiding this comment.
Isn't there's an npm package we can use instead?
Reduces maintenance headaches for something that's very generic.
There was a problem hiding this comment.
I was trying to avoid adding a new dependency. :) I'll look for a suitable library.
| * } | ||
| * | ||
| * const s = new MyStub(); | ||
| * mod.func = s.someFunc; // monkey-patch |
There was a problem hiding this comment.
What's wrong with typemocks that already allows you to create mocked classes, this is a reinvention of a wheel here.
Please remove before merging.
I'm a strong believer if using existing libraries, that are well tested, and it makes it easier for others to use as well. E.g. if we need to support async meetings, you'll need to change code in this stubs framework, i.e. slippery slope of maintaining code that's already supported by other libraries.
|
I'm going to land the change with the stub left in. IMO, doing it with mocks instead is much harder to understand (and write). @DonJayamanne, we'll have a discussion about this when you get back. If we decide that mocks are the one true way then I'll switch this code to use mocks. :) |
d3r3kk
left a comment
There was a problem hiding this comment.
Your solution looks fine to me, and I look forward to having the conversation re:stubs vs TypeMoq when @DonJayamanne returns.
One thing to consider, open an issue to discuss this type of change and label it as P0 for Sept milestone!
Everything addressed except for stub concerns.
(fixes #2245)
"1.2.3", not"^1.2.3")package-lock.jsonhas been regenerated if dependencies have changed