vscode-python is missing bundled libraries

[mammo0]

Hello,

similar to #711 the package vscode-python also misses a bundled library directory:
pythonFiles/lib/jedilsp

For more information please have a look at microsoft/vscode-python#22176

[filiptronicek]

Hello there @mammo0 👋. We have now republished the affected version of the Python extension. Could you try if it works for you now?

[mammo0]

Hello @filiptronicek ,
thank you for looking into this. I will test the updated package tomorrow.

But if the missing directory is now in the package, everything should be fine. Because in the meantime as a workaround I just copied the missing directory from the MS marketplace package to the corresponding directory of the installed extension and this worked without problems.

[mammo0]

Can confirm, it's working now 👍

Thank you :)

[libreom]

Installing the extension from codium itself results in same errors, it was fixed after downloading from website in a browser and then installing

[filiptronicek]

@libreom VSCodium may still be serving the extension from cache. See #711 (comment)

[toadjaune]

Hi folks, I just hit this issue, and had to manually clear my CachedExtensionVSIXs cache to fix the issue.

I was wondering, in situations such as this one, would it be possible to artificially change the version number to invalidate stale local cache ?

Since clients have a local cache enabled by default, editing a release bundle after the fact sounds like something we should avoid, wouldn't you agree ?

[filiptronicek]

@toadjaune agree the status quo is not ideal: making sure we resolve broken extensions effectively is an important step in the resolution process, which VS Code struggles with, because it expects published versions to be immutable.

This is a tough problem though, because we cannot just "change the version number", since the upstream extension (such as Python in this case), might publish that version after us, which creates a big amount of confusion for both us and our publishing pipeline. I am not sure of an immediate fix other than manual cache invalidation, but this would have to be an effort on the side of the IDE itself, with perhaps some UUID additions to the Open VSX server.

I also agree with your perspective of editing released versions at all – this should be avoided whenever possible, but our tooling and processes don't account for that yet. I will deal with future issue on a case-by-case basis, but will keep this in mind. Thanks!

[toadjaune]

I was thinking maybe we could extend the upstream versionning scheme ? Like, if upstream makes x.y.z (like they seem to currently be doing), maybe we could extend this to x.y.z.a whenever we need to publish a patched versions that is different on our end, but based on the same upstream release ?
I'm not sure how constraining vscode is on version numbering shemes though.

Anyway, thanks for your answer !