Ease support of remote environments

[AlexTalker]

First of all, I totally admire the the work done in this project. This is the 3rd VS Code extension I'm trying today and so far seems quite promising, however, I need to give more context.

I'm currently trying to being using code-server in my development routine, since I was long yearning for a nice in-browser IDE that can be deployed on my in-office PC. The nature of my development environment happens to be that the code in the current workspace/project gets deployed onto remote machine(available via SSH) that contains all of the necessary dependencies, required for it to be successfully executed. Keeping the dependencies or trying to run them locally in a container is 99% unfeasible due to the architecture.

I however would fancy very much to have auto-completion and insight into all of the available code(the project and its 3rd party dependencies) on the office PC I run code-server from.

Due to glorious licensing issues, only VS Code currently has Remote Extensions support, so I can't utilize that for your extension.

I saw the discussion in #33 regarding executing Perl in Docker and I tried to do the same with SSH but failed since Perl scripts that make bulk of the actual work are hidden as assets of this add-on and path to them can't be mangled with via the configuration.

Thus, I propose those few following steps to improve the situation:

• Isolate Perl code so that it can be built/delivered separately if required
• Ensure that LSP Server code depends on Perl code only by execution and not by sharing files(this translates harder via stuff such as SSH)
• Allow parametrize the path to the Perl code, instead of hard-coded path to the assets
• Publish actual version of the extension to https://open-vsx.org/extension/bscan/perlnavigator so that other projects based off VS Code can have easier time accessing it

I assume that after this hopefully simple clean up, it would barely matter whether the environment is a container, a remote machine or something else, as long as execution of Perl code can be delegated there.

So far I've tried https://github.com/richterger/Perl-LanguageServer which has somewhat poor auto-completion and https://github.com/FractalBoy/perl-language-server which unexpectedly ceases to function over SSH, possibly because an issue similar to FractalBoy/perl-language-server#103 or not. So my hopes for "the third time is a charm" case are quite high =)

[bscan]

This is a good idea, and would also help with Docker and WSL support (for people who aren't using the respective Remote Extensions). I believe the easiest way to support this would be adding the Perl code to CPAN so that it can be installed independently. Then there could be a configuration setting to use the installed version instead of the extension bundled version. Would that type of solution work for code-server?

[AlexTalker]

@bscan I feel that for CPAN the code hierarchy needs tidying up(and using something like ExtUtils::MakeMaker or such https://wiki.archlinux.org/title/Perl_package_guidelines#ExtUtils::MakeMaker ), as it now more of a collection of hacky scripts loosely tied up together =)

But sure, that's one way to go about it. It also would highlight the dependencies for this part of the code, which I think are quite minimal but still =) I'd say generally anything works as long as it gets split up from the JS/IDE part, since this extension isn't about supporting Node.js completion or something, so ideally only Perl part needs to be portable.

[AlexTalker]

@bscan I have given it some more thought and I think there's a 5th step that would be next to required for such advanced scenarios: customizable mapping of paths. In https://github.com/richterger/Perl-LanguageServer this is already supported but I feel with extra inspiration from https://github.com/FractalBoy/perl-language-server where configuration allows to reference workspace directory, this will help with "Go to definition" functionality for the scripting language.

Also, regarding note on a filesystem, stuff like configuration files for perlcritic and such might be better suited to be passed as content rather than a path to the Perl code.

Does these improvements still sound sane enough? =)

[bscan]

as it now more of a collection of hacky scripts loosely tied up together =)

Haha, pretty accurate. The overall design of the Navigator is certainly fairly unusual. The reason it is node.js based is for portability reasons and ease of install. For most uses, you can simply install from the Marketplace and it will just work. No need to do any cpan installs or use a package manager. Similarly, due to the bundling, the perl code automatically stays updated with new releases, and there's no opportunity for mismatch between the perl code and the vscode extension. Being in node.js also allows me to leverage the Microsoft LSP libraries, which is also nice for compatibility and stability.

It also would highlight the dependencies for this part of the code, which I think are quite minimal but still =)

All dependencies are currently bundled in the extension, which enables the Navigator to work against a bare bones install of Perl anywhere as old as version 5.8. The two bundled dependencies are Class::Inspector and Devel::Symdump.

For the remote running, I'm surprised code-server doesn't have a more comprehensive solution for dealing with these things. For the vscode remote extensions, all extensions simply work without any modification. Otherwise, it seems like all extension developers would need to add the workspace mappings and similar.

Overall yes, it makes sense though. WSL has a similar mapping need where a file may be /mnt/c/foo.pl on the linux side and would map to c:\foo.pl when accessing files from the Windows side.

[bscan]

I just gave code-server a try and it worked very well for me out of the box. The OpenVSX version of Perl Navigator also worked instantly without any configuration at all (image below). Overall I'm very impressed with code-server, and I'll make sure to upload new versions of the Navigator to open-vsx to support it (and the other open source vscode variants). Although now I'm also re-reading your initial request and trying to understand what you are trying to do. If you have a remote development environment, why not run code-server directly on that environment? I believe that's the core purpose of code-server to begin with.

[AlexTalker]

@bscan Yeah, I probably should rephrase the description of my issue more clearly. It is true that your extension works fine in code-server, I just highlighted that I want to use code-server instead of the all-power with proprietary code support VS Code since I would like to have in-browser IDE interface, I just find it convenient. It really barely matters whether I use code-server or Theia(which unfortunately lags behind code-server in my opinion) or any other fork pretty much since Remote Extensions won't(at least legally) work on any of the forks to possibly(I haven't really tried it much) give me the edge I need.

And thus, the real struggle is that I want/need to have IDE with completion and stuff on one machine(where Git and currently open workspace is) and language server or whatever backs it up on another(where final artifact is deployed, yielding the same code just by a different path 95% of the time), since I find that it's the advantage of the technology - language server can be deployed somewhere else than the client in order to provide most benefit.

It would be a real hustle to use code-server or anything else where language server is deployed for one reason or another but at the very least in the fact that for Perl support it is enough to have only Perl code there since it will work wherever the interpreter is ported to and not whether Node.js and the whole enormous tree of dependencies of the IDE is. For example, code-server is currently bundled only for amd64 and aarch64 architectures, and riscv64gc is something of a rising star but where one could run Perl code and even language server, running a whole IDE backend would be more on the suicidal side =)

I'd say it's pretty much the same deal with containers, especially if one targets K8s, where it would be a real hustle to put whole IDE in there in place of just a few extra Perl dependencies.

Hope I get my point across.

In that maybe somewhat extra complicated but really "enterprise" setup, https://github.com/FractalBoy/perl-language-server currently mostly just works, if only it had path mapping =) But I'm really interested in trying out what you've done here once such configuration will be possible