Enable serving on public interfaces

[alexgarel]

in (LanguageServer.pm:L468)[https://github.com/richterger/Perl-LanguageServer/blob/b765182cfb3/lib/Perl/LanguageServer.pm#L468] the server listen on 127.0.0.1 with no way to tell it to listen on a public interface.

When you run the LanguageServer in a docker container you can only publish ports from the container public interface. So there is no way to talk to the LanguageServer from the outside.

Could we add a --host option for that, passed directly to tcp_server call

[ecos-ps]

I added this feature in a first draft here: https://github.com/ecos-ps/Perl-LanguageServer/commit/1d2e9a9e2c5464657c86544da9f5648c01027e1d Didn't test it by now, didn't have time for it. Have to add it to documentation as well, probably i got time for that in the next few days. Would be glad if you can test it.

[alexgarel]

I added this feature in a first draft here: https://github.com/ecos-ps/Perl-LanguageServer/commit/1d2e9a9e2c5464657c86544da9f5648c01027e1d

I had quite a hard time figuring out how to install the module from your git (and had to modify the extension.js myself) but I did it, but here it goes, crashing:

launching perl -I/opt/product-opener/lib -I/opt/perl/local/lib/perl5 -MPerl::LanguageServer -e Perl::LanguageServer::run -- --port 13603 --host 0.0.0.0 --log-level 2 --log-file  --version 2.3.0
Creating po_backend_run ... 
Creating po_backend_run ... done
Attribute (host) does not pass the type constraint because: Validation failed for 'String' with value 127.0.0.1 (not isa String) at /usr/lib/x86_64-linux-gnu/perl5/5.28/Moose/Object.pm line 24
	Moose::Object::new('Perl::LanguageServer', 'HASH(0x56111e259fe0)') called at /opt/perl/local/lib/perl5/Perl/LanguageServer.pm line 602
	Perl::LanguageServer::__ANON__ at /opt/perl/local/lib/perl5/x86_64-linux-gnu-thread-multi/Coro.pm line 716
	Coro::_coro_run at -e line 0
255

(the launching... part is my script telling command I will run)

[alexgarel]

FYI, this seems to fix it (on https://github.com/ecos-ps/Perl-LanguageServer/commit/1d2e9a9e2c5464657c86544da9f5648c01027e1d)

diff --git a/lib/Perl/LanguageServer.pm b/lib/Perl/LanguageServer.pm
index 4ab606a..9955501 100644
--- a/lib/Perl/LanguageServer.pm
+++ b/lib/Perl/LanguageServer.pm
@@ -160,7 +160,7 @@ has 'listen_port' =>
 has 'host' =>
     (
     is => 'rw',
-    isa => 'String',
+    isa => 'Str',
     default => '127.0.0.1'
     ) ;

[alexgarel]

(edited above comment, because the Maybe was'nt necessary)

[richterger]

@alexgarel, it would be much more easier if you have ssh running inside your Docker container, to use the ssh options, which will tunnel all necessary ports for you

Von: Alex Garel @.*** Gesendet: Donnerstag, 24. März 2022 09:59 An: richterger/Perl-LanguageServer @.> Cc: Subscribed @.> Betreff: Re: [richterger/Perl-LanguageServer] Enable serving on public interfaces (Issue #131)

[alexgarel]

@richterger docker-compose can redirect ports, but yes, in my removed comment, what I fall into was because

• in _run_tcp_server in @ecos-ps patch, we don't have a distinction between listen_host and host of connecting client, but I can manage making the difference
• in the line $ENV{PLSDI_REMOTE} = $self -> debug_adapter -> host .':'. $self -> debug_adapter -> listen_port ; you have to handle the special case of host being 0.0.0.0 (in which case you can use 127.0.0.1).

I am able to propose a patch for this scenario, but are you interested in it ? (I can understand one wants to limit features).

On my side I think it's really manageable to add ssh server as this is an already supported scenario.

[richterger]

@alexgarel I just wanted to point out that using ssh maybe a easyer way to go, but this depends on your use case. If you provide a patch as pull request I am happy to integrate it. I am just not have the time to do the work on my own. If you provide a patch, please also add some documentation about the use case and setup to the README, so other people can benefit from your work as well. P.S. I saw in the ticket you mentioned, that you also want to use perlcritic. That one of the things I also like to have in Perl::LanguageServer. The integration is much the same as for perltidy, just in case you want to take a look at it...

[ecos-ps]

FYI, this seems to fix it (on ecos-ps@1d2e9a9)

diff --git a/lib/Perl/LanguageServer.pm b/lib/Perl/LanguageServer.pm
index 4ab606a..9955501 100644
--- a/lib/Perl/LanguageServer.pm
+++ b/lib/Perl/LanguageServer.pm
@@ -160,7 +160,7 @@ has 'listen_port' =>
 has 'host' =>
     (
     is => 'rw',
-    isa => 'String',
+    isa => 'Str',
     default => '127.0.0.1'
     ) ;

typical error when switching from other programming language and programming in blind mode... sorry for that!

Fixed in https://github.com/ecos-ps/Perl-LanguageServer/commit/6905c779f5dd9d22b1e90fb745337c5d50907f95

[alexgarel]

@richterger for your information, I'm working on this, I will do a PR soon.

[richterger]

@alexgarel I am also thinking about how to work inside a container (kubernetes in my case). Could you explain a littel more to me , how your setup is:

1. You are editing outside of the container, so you need the LanguageServer running outside the container for syntax checking and symbols etc., but you want to run the debugger inside the container (Perl::LanguageServer is installed inside and outside of the container)
2. You working completly inside the container (Perl::LanguageServer needs only to be installed inside the container)
3. Sometning different...

(2) works for me out of the box with the remote container extention, when using docker, but not for kubernetes.

[alexgarel]

Yes I'm in case 1.

In my case this is a project using docker-compose, and different containers, each specialized. (https://github.com/openfoodfacts/openfoodfacts-server/)

I'm running vscodium on my desktop, and would like to debug perl inside the container. (for now I try to debug in tests, next step will be to debug in Apache, but I'm not there !). I describe it a bit here : https://github.com/openfoodfacts/openfoodfacts-server/blob/main/docs/how-to-guides/use-vscode.md

I will push a draft of where I am. At the moment my two problems are:

• I implemented the DA "source" command but it sends path that are not path (should be easy to fix by being tolerant) (eg: "(eval 3641)[/opt/perl/local/lib/perl5/Test2/API.pm:72]"
• If I work on ./t/lang.t (a test), vscode interpret it as being a file at /t/lang.t I don't know yet why (it's annoying because then I can't put breakpoints in my file before launching debugger)

Here is my draft PR: https://github.com/richterger/Perl-LanguageServer/pull/135 (I do more than one think at once, because my goal is to have it working in my project).

[richterger]

I am still not 100% sure that I understand your usecase correctly. Maybe you could post your settings for the perl extention and the lauch.json or you just explain a little bit more your network setup.

[richterger]

Just saw you explained it in https://github.com/openfoodfacts/openfoodfacts-server/blob/main/docs/how-to-guides/use-vscode.md . So just ignore my last comment.

[richterger]

@alexgarel I just started the container support for Perl::LanguageServer. Debugger is not yet supported, but maybe it's worth taking a look at 9790a3c3c33032ac8ebb96adfd82d31679972d2d

That allows you to do something like the following in your settings, to avoid the extra shell script:

        "perl.containerCmd": "docker",
        "perl.containerName": "c416857756c709e556670b6ba0a2ca228d1061338b310aaf80313ec951c6e622",
        "perl.pathMap": [
            [
            "file:///usr/share/perl5/Perl/",
            "file:///usr/src/apps/Perl-LanguageServer/lib/Perl/"
            ]
        ]    

or

        "perl.containerCmd": "kubectl",
        "perl.containerName": "pod-67676f47df-h5b9z-65qjc",
        "perl.env": { "KUBECONFIG": "/etc/rancher/k3s/k3s-dev1.yaml" },
        "perl.pathMap": [
            [
            "file:///usr/share/perl5/Perl/",
            "file:///usr/src/apps/Perl-LanguageServer/lib/Perl/"
            ]
        ]    

It should also work for docker-compose, but I do not use docker-compose, so it's not tested yet. A brief description of the new options, can be found in package.json. I plan to add Debugger support as well as soon as possible