Add support for LS inside of Docker containers

[kieferrm]

Trying to start the language server in a docker container that is using a docker images based on python:2.7-slim fails with the following exception:

Starting Microsoft Python language server.
FailFast:
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

   at System.Environment.FailFast(System.String)
   at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
   at System.Globalization.GlobalizationMode..cctor()
   at System.Globalization.CultureData.CreateCultureWithInvariantData()
   at System.Globalization.CultureData.get_Invariant()
   at System.Globalization.CultureInfo..cctor()
   at System.StringComparer..cctor()
   at System.AppDomain.InitializeCompatibilityFlags()
   at System.AppDomain.Setup(System.Object)
[Error - 22:01:52] Connection to server is erroring. Shutting down server.
[Error - 22:01:52] Connection to server is erroring. Shutting down server.
[Error - 22:01:52] Connection to server is erroring. Shutting down server.

When following the hint given in the error message and adding the following to Microsoft.Python.LanguageServer.runtimeconfig.json the server starts up:

{
  "runtimeOptions": {
    "configProperties": {
      "System.Globalization.Invariant": true
    }
  }
}

[MikhailArkhipov]

Probably b/c of non-interactive environment. I guess we could set the flag by default and set it back if client passes down actual locale.

[MikhailArkhipov]

We should probably set mode to non-interactive as default, implement #98 and if server passes locale then flip to interactive.

[AlexanderSher]

Is there libicu package in your docker image?

[AlexanderSher]

Microsoft.Python.LanguageServer.dll in simple container on top of the 2.1-runtime has no errors with CultureInfo. Our tests in container on top of the 2.1-sdk pass as well.

[AlexanderSher]

Microsoft.Python.LanguageServer on top of microsoft/dotnet:2.1-runtime-deps-stretch-slim also works (until it tries to run interpreter)

FROM microsoft/dotnet:2.1-runtime-deps-stretch-slim AS run
WORKDIR /usr/src/app
COPY output/bin/Release/linux-x64/publish .
ENTRYPOINT ["./Microsoft.Python.LanguageServer"]

[MikhailArkhipov]

There is not much for the LS to do here. .NET Core has dependencies on certain platforms that are not installed automatically unless user installs .NET Runtime.

The example above is about missing libicu and although it could be worked around with the config file (with loss of localization) there is no guarantee that this is the only dependency LS needs. I.e. it is not a bug, it is a dependency required by .NET Core. In fact, it is .NET Core that is attempting to load libicu, LS code has not been even loaded yet.

It is generally up to the client to ensure appropriate runtime environment. LS is technically packaged as runtime-independent, but as .NET Core goes, not all dependencies are actually packaged and some have to be installed manually by the user.

[gramster]

Let's not let the perfect be the enemy of the good here. While it may not be ideal, we want these remote scenarios to work for our customers. If we can solve this particular problem with a workaround and unblock people we should do so. If we later find other missing dependencies we can revisit this approach but for now this is the one we know of and it is a low cost workaround. Moving this back to the backlog.

[MikhailArkhipov]

microsoft/vscode-python#5247 resolves in VS Code. Otherwise it is up to the installer to lay down appropriate configuration file or choose container with either dependencies or .NET Core runtime.