Support for container-perl

[bscan]

Support for container-perl

[bscan]

Looks great, thanks @EvanCarroll! I was looking into something similar for Docker. I recently got the following gist from @tyrrminal https://gist.github.com/tyrrminal/ca546fd61bf8414dbeb3b49fbc0ed881 . He used a shell script as the perlNavigator.perlPath with a pre-constructed docker command to enable use in a container. It doesn't mount the paths from %INC as yours does, but I think the purpose was slightly different. @tyrrminal develops using a standardized container from $work with his dependencies and wanted to use that container with the Navigator (and possibly varying per workspace). The container-perl seems like it allows the recreation of a local environment in a container for the purposes of secure compilation. Both are cool usages of containers; it could be worth supporting all the different cases.

Thinking out loud here, perhaps the settings are something like:
containerName: foo: "exec" perl -c in pre-existing and currently running container foo (easiest option to support).
containerImage: bar: "run" perl -c in new temporary container built from image Bar. Option is mutually exclusive with containerName
containerEngine: <str: docker or podman>:
containerIncreplace: <boolean: default False>: Map all of %INC into container using libReplace
containerMapIncPaths: <boolean: default True>: Mount all paths from perlNavigator.incPaths into container.
containerMountPaths: <array>: Additional paths to mount in container (but not added to %INC).

[EvanCarroll]

Well, the idea here is for the purpose of syntax checking and less XS-incompatibilities you shouldn't /need/ a custom container. That is to say,

• if you have dependencies on your development machine, you should be able to just map them in. There is nothing that I can think of that wouldn't work with this method less XS-dependencies which shouldn't make a difference for the purposes of perl -c.
• if you don't have the dependencies on your development machine, I think that's a different problem entirely. The obvious solution there is simply to install them. I agree we can support this, but it's not really the job of the LSP-client to support this. While it's normal to distribute an application to end user in an image for launch in a container, if a developer asks for your dependencies and you ask them to develop in a container that's a bit awkward. Normally containerization isn't used like that. I would want to know more about the use case here. What kind of dependencies does your code place on perl such that perl -c will execute different in one environment without them.

Also from that script above, it seems they still do what I'm doing except they're a bit less rigorous,

  -v "${HOME}/srv/perl5/lib/perl5:/development/perl5/linting"  `# Link local::lib with just Perl::Tidy and Perl::Critic into container` \

The container-perl method will catch everything in @inc. Not just local::lib under that configuration.

As for docker and podman, they're fully API compliant. We can replace podman with docker, if you don't have podman. But it's fully available for Windows. On Linux however, it's just a superior piece of technology with full rootless support (so nothing has to run as root).

[bscan]

Thanks! Personally, I don't use containers much, but I've seen the request before for developing in them. For example, in the other Perl Language Servers, there have been a few people asking for similar functionality: https://github.com/richterger/Perl-LanguageServer/search?q=docker&type=issues
https://github.com/FractalBoy/perl-language-server/search?q=docker&type=issues

vscode provides some support for developing inside containers (including using podman): https://code.visualstudio.com/docs/remote/containers , and this will run a vscode server within the container. Perl Navigator should work automatically in this scenario, as it gets installed inside the container. However, this is pretty heavy-handed, and only applies to vscode, not any other editors.

Overall I agree with you that container-perl would cover a much broader set of applications for all editors. I'm happy to help out if you want to bounce ideas off anyone, but you're already off to a great start. Thanks again!