Multiple versions of typst

[memeplex]

I've been using typst-lsp + typst-preview as suggested here and the UX is excellent.

The only thing I dislike is that I ended up with three different versions of typst (cli, lsp, preview) since it's linked into each bundle. This may be because of performance reasons or more related to rust development practices, I don't know. In practice I had no issues but I can imagine myself bumping into some corner cases were the different versions are not entirely compatible.

Is there any envisioned solution to this or do we have to learn to live with it? Ideally I would like to install typst in my system with, say, brew, and set the different Code extensions to use that version, as it's usually the case with other extensions.

[Enter-tainer]

This may be because of performance reasons or more related to rust development practices

The tricky thing is that typst-cli is not enough to build a previewer/language serer. You need get access to the internal data structure of typst. So it is needed to use typst as a library. I believe this is common practice: clangd and rust-analyzer should also have a c++/rust frontend bundled inside of it.

[memeplex]

The tricky thing is that typst-cli is not enough

I see, when I referred to "rust development practices" above I meant something like this. For traditional packages say that I'd installed typst using brew, then a shared object would be available in the system for other packages to dynamically link to it. But perhaps this is not common practice with rust and I know it replaces the "version hell" with a "dependency hell", although it has some advantages as well.

[memeplex]

One more remark, this may be taken as a mild argument for typst-lsp/preview to join forces. If there were a single extension that also let you produce a final document, then you'd only need one typst installation.

[Enter-tainer]

For traditional packages say that I'd installed typst using brew, then a shared object would be available in the system for other packages to dynamically link to it. But perhaps this is not common practice with rust

Only C has a stable ABI. To make the .sos useable, even if you use C++/rust, you still need to expose a C interface. This is OK for end libraries but not suitable for compilers and language servers. They need pass complex tree data structure around.

There has been debates about dyn vs static linking all the time. I wouldn't want to talk much about it. For rust binaries, static linking is the easiest solution.

[memeplex]

Sounds reasonable enough, thanks!