Allow use of custom JANET_PATH/JANET_TREE etc.

[tionis]

I have a setup where my Janet deps live in a user-local folder, allowing the user to specify things like the $JANET_LIBPATH, $JANET_PATH, $JANET_PROFILE, $JANET_HEADERPATH etc. would allow users to use their custom environments.

[CFiggers]

I've been working on this over the last few days and I might have a (temporary?) solution for you.

Could you please try running janet ./src/main.janet instead of the compiled janet-lsp executable and let me know what, if anything, changes?

[tionis]

I'm currently using it via the vscode extension, how can I run a custom lsp server with it?

[tionis]

I just realized that this may be more of a problem with https://github.com/CFiggers/vscode-janet-plus-plus
Maybe just setting some env vars in the extension before starting the lsp server might work?

[CFiggers]

Oh good, if you're using Janet LSP via Janet++ then this is super easy! Just go to the Janet++ extension page and click "Switch to Pre-Release Version":

If it works well for you then you'll be the fourth person (that I know of) for whom this release candidate is more stable re: module discovery and I'll be moving it toward general release ASAP.

[tionis]

I don't have this option, possibly because I'm using the OSS version of vscode.
I'm currently traveling, but I could try it out with the Microsoft version later

[CFiggers]

Ah, understood—here, let me push the update to the Open VSX registry so you can give it a try.

[CFiggers]

That's live now on Open VSX—I don't know how long it will take to propagate but once you see it it should be good to go :)

[tionis]

Thanks! I just tried it out, and it works, no configuration needed!
How does it work under the hood?

[CFiggers]

I appreciate the question! 🙂 Which "it" are you referring to? The LSP as a whole? Or specifically this update that makes it work with user-local installs?

Assuming you probably mean the latter, it's working by shipping a .jimage file rather than a compiled executable, which is what we were doing before. The extension checks your path to make sure that janet is available—if not, it doesn't start the LSP, but if so it invokes your own Janet install, wherever you have it, to load in the .jimage and run the server from there.

That has a couple of benefits—for starters, it's intrinsically cross-platform (Windows, Linux, Mac, BSD, NixOS) and architecture-indifferent (x86_64, Arm64, M1 Apple Silicon, Raspberry PI, RISC-V, even TIC-80 I presume—anywhere Janet works, the LSP should also work seamlessly). And all that WITHOUT needing me to compile and ship separate executables for each OS/Architecture combo. Janet runs as an Abstract Machine anyhow, may as well get the benefits of it!

Second, since it's running on YOUR Janet install, it'll always have access to any libraries you have installed and it'll error on any you don't—I don't need to know in advance what you have installed, or don't, or where you put them. If YOUR Janet can find a module, then so can the LSP, because it's literally running on YOUR copy of Janet. That also means the LSP can warn you when you are trying to import a library that you haven't installed yet.

Third, we shouldn't have any issues with Janet version mismatches, like if you update your Janet to 1.32.1 but the last time I built and distributed Janet++ I was running Janet 1.31 (this happened last week—there's a closed issue about it somewhere). From this update on, the LSP is running on YOUR Janet, whatever version that may be. So, for e.g., if bakpakin adds new core functions in 1.33 and you update, those will automatically be recognized for hover-over documentation (since YOUR updated Janet will have them in its environment table, so the hover function will have access to call :doc on them, all of which will work without me needing to ship a new version of Janet++). I would still need to add those new functions to the syntax highlighting in Janet++, but the hover docs will instantly work regardless.

There's nothing magic about the .jimage specifically, all the same benefits would apply if I shipped the full Janet source for the LSP and had Janet run it as a script. The .jimage just saves a bit of startup time because Janet doesn't have to compile before running, and it makes the build process on my end a little cleaner, since the LSP can ship as a single .jimage file rather than multiple .janet files in a directory tree.

[tionis]

I see, cool setup!
I gotta read up in Janet's Handling of it's lib paths. I thought they needed the Env bar set for a setup like mine.
Kudos, the plugin/lsp works like magic! 😄