[feature] vscode: setting: introduce `slint.lsp-path`

[spikespaz]

Platform: Linux intrepid 6.5.10 #1-NixOS SMP PREEMPT_DYNAMIC Thu Nov 2 08:37:00 UTC 2023 x86_64 GNU/Linux
Language: Rust/irrelevant

I'm not sure if this should be considered a bug, but as I am using NixOS and use locally built packages for 99% of the system. I would like to specify the path of the slint-slp executable in VSCode settings.

These are the options that I could find for Slint:

slint.includePaths
slint.libraryPaths
slint.lsp-args
slint.preview.providedByEditor
slint.preview.style

Could we perhaps specify arg 0 with slint.lsp-path?

[ogoffart]

Thanks for reporting an issue.

This has already been discussed in #2577

What I have written in my comment there is still valid: I'd accept a pr for that.

[hunger]

Also as mentioned in #2577: This is not going to work in practice as the VSCode extension uses custom extensions to the language server protocol and slint-lsp ansd the extension need to match. I am open to provide a build time switch for the VSCode extension so that nixpkgs can configure this, but a run time switch seems too dangerous to me.

[ruffsl]

I am open to provide a build time switch for the VSCode extension so that nixpkgs can configure this, but a run time switch seems too dangerous to me.

What do you mean by "build time switch"? Is that something that could the extension itself could do upon clicking install from VSCode's Extension Marketplace?

as the VSCode extension uses custom extensions to the language server protocol and slint-lsp ansd the extension need to match.

As of 2025, Is this still the case? Has the need for such custom extensions changed or improved? I.e. the modern stable version of the standard LSP interface suffices for user needs?

[hunger]

@ruffsl: By build time switch I mean something you can set when building the VSCode extension yourself. I assume that is what nixos people will be doing, considering that they report the slint-lsp is not found -- which it should be when the extension is installed from the VSCode market place.

Even in 2025 the VSCode extension and the language server must match (relatively) closely :-) Most things will work one way or the other, but I expect breakage if they differ too much.

I still made a patch (#8964) that enables people to override the slint-lsp to use... If you do, you are on your own of course.

[spikespaz]

I think @hunger means something like a feature flag at compile time, but I'm not involved with NPM so don't know the proper terminology. Regardless, I don't think the option should be conditionally compiled. It should always be enabled for all users. Add a disclaimer if you want, but for many extensions, that's a perfectly normal option to have, and commonplace--nay, mandatory--for other editors.

As for the rest, Nix doesn't override anything to do with the VS Code extension, it just doesn't provide a standard FHS environment for VS Code unless specifically opted-in. Most extensions, no matter where they come from, struggle to download and configure external tools--because that isn't something Nix users want, it breaks determinism and is not reproducible at any point in time.

We much prefer to explicitly define all dependencies. That means the version of the VS Code extension, and slint-lsp, we would define which version of each to use in our configurations. They should be kept in lockstep, and that's the Nix user's responsibility.

Many times, users will prefer to download packages from OpenVSIX, not the Marketplace. Even if it is from Marketplace, we'll cache an endpoint to download an exact version of a file.

[tronical]

The rephrase what @hunger said by turning it into a question: Do Nix folks take the Slint VS Code extension and package it, in a way that Nix users will install it via Nix instead of downloading the extension from the VS code market place or OpenVSIX?

[spikespaz]

@tronical Depending on the extension. This one doesn't need to be re-packaged, and we can just download the VSIX from some endpoint. Some users may desire to build from source, but that's rare for VS Code extensions.

All that Nix (or more accurately, Home Manager) is going to do is download the file, hash it so it always knows exactly what version is used for this particular build of the system/home, and then put it in the VS Code extensions directory.

Sometimes, extensions need patches. If they do, you might find them in Nixpkgs, otherwise, there's a function to download directly from Marketplace or OpenVSIX.

[tronical]

Thanks - that helps in understanding.

If Nix/Home Manager end up downloading the .vsix, what motivates the desire to replace the slint-lsp binary that's within the extension with a custom one?

[spikespaz]

That depends on where the extension keeps the binary it downloads. If it keeps it in some directory that's supposed to be immutable (managed by Nix) it needs to be patched, or better, use a file that is also managed by Nix.

The idea of Nix is that all software exists in /nix/store, each package and configuration file lives in a directory that is named according to the hash of its dependencies. Then, other programs that reference said libraries/configurations/binaries should have a shim or a patch that tells it exactly which hashed store path to use for that particular dependency. In this way, everything is tracked. Provided you have the configuration that produced a system or a home directory (the immutable parts), you can re-build that exact system at any point in time. And, because everything is named with a NAR-hash, you can have multiple versions of the same software on a single system, be it library or binary. For binaries, you obviously musn't have multiple identical binaries listed on PATH, but if you make wrappers or trampolines to start the different versions (pointing to the correct store paths) it all works fine.

Linux FHS is a standard (well, really just a convention) that says "binaries live here, libraries over there", and Nix breaks that convention in favor of wiring everything up directly. Ideally, in a world where deterministic configuration was not an afterthought, everything would be wired up exactly and perfectly, to the point that it's all portable. What runs on your machine is the exact same thing that runs on my machine.

Obviously, determinism, and by extension reproducibility, is the antitheses of globally shared mutable state (which FHS is, the state of the system, and often mutable), and we require patches or features like this to work around the fact that we can't eliminate the root of all evil.