Ease support of remote environments
AlexTalker opened this issue · 6 comments
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 asSSH
) - 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 =)
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
?
@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.
@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? =)
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.
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.
@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