Jacek Sieka

> Counterpoint: It's possible to bundle platform-specific binaries by providing platform-specific VSIX files: it is also possible to bundle all binaries in a single vsix and choose a binary at...

On how to bundle maximally compatible binaries that don't depend on distro specifics: https://github.com/nim-lang/vscode-nim/pull/46#issuecomment-1962918651

Hey, it's Sunday, we're allowed to rant ;) > it's slow. Slow is not where the inefficiency comes from: the increased complexity lies in having to maintain compatibility across version...

> it also downloads and compiles the Nim compiler from source fwiw, it does this only if the installed nim version does not match the expected version - also, the...

> And how would that better ux/feedback look like? A console window showing nimble downloading and compiling stuff? the `go` extension for example creates a separate output window (for all...

> This makes the user's installed nim version almost never match the expected version. ok, that's a bit weird - for an app like nls, I'd expect it to lock...

> it comes with whatever Nim compiler they've got. This is something to change as well and we'll be moving away from it in general - ie when nimble "drives"...

> this isn't done yet this is simply a matter of priorities and addressing the issue at the core before introducing workarounds in "leaf" projects like vscode-nim (which also cost...

> If we're going to bundle it with the extension, we might as well bundle nimlangserver instead and skip the entire compilation step. Yeah, well, _generally_ I think bundling or...

> in case linking with glibc really does create problems between distros. the simple rule when using glibc is to compile on an old distro (like ubuntu 18 LTS), usually...