ms-toolsai.jupyter version 2023.3.100 is actually not 2023.3.100 (?)

[xaberus]

Compare the following:
Open-VSX

"engines":{"vscode":"^1.76.0"},

Visual Studio Marketplace

"engines":{"vscode":"^1.77.0"},

vscode-jupyter@2023.03.100

"engines":{"vscode":"^1.77.0"},

all of the above must (roughly) refer to the tag 2023.03.100 or a later commit. This implies that the engines field in package.json should be set to "vscode": "^1.77.0" as of commit microsoft/vscode-jupyter@42f6c0e.

This is true for the Marketplace VSIX and for a locally build VSIX from source - yet the Open-VSX contains the line "vscode": "^1.76.0". (also some files in the package do not match the local build). How is this even possible?

As a result, the 2023.03.100 version from Open-VSX results in strange bugs in VSCodium (removed API proposal for python kernel kind selection).

[filiptronicek]

Hey there @xaberus, thanks a lot for noticing this. The last version that we published, 2023.03.100, does not reflect the commit you mentioned and therefore that is not yet released (we published it 30 days ago in the beginning of March). We could not release new versions because of microsoft/vscode-jupyter#13260.

[xaberus]

@filiptronicek Argh, that makes sense now. I also saw the hang mentioned in microsoft/vscode-jupyter#13260 when building by hand, but thought that it was on my end because my nodejs v18 install...
Thank you, for confirming! I thought that I was missing something 🙈

[xaberus]

So the actual problem is that the build script:

• was triggered by the new tag 2023.03.100
• ran into a timeout and failed
• the failure did not abort the pipeline
• presumably the artifact from the last build was still there and got picked up as the result of the pipeline

Am I correct?

[filiptronicek]

I believe this was even simpler: the tag has been created 2 weeks ago, just after the commit we are talking about. The version in the package.json has most likely been there for some longer time, so the publishing script already published it incorrectly in early March.

[jeanp413]

@filiptronicek it would be good if we are smarter how we check a new stable version is published in MS marketplace before doing so in openvsx, can we use vsce show <ext_id> --json command to get the extension info in our script before publishing?
also jupyter uses release branches maybe we can add a new field in the extensions.json file to check for branches with a pattern instead of using main branch
what is the plan for the broken version 2023.3.100? I see there's already a 2023.3.120 so maybe just leave it broken and publish the new one?
finally the extension version no longer matches the version in MS marketplace as they add some more numbers after the version in package json (maybe a timestamp?) we can match it if we can use vsce show <ext_id> --json to get the exact version

[filiptronicek]

Thanks @jeanp413 🙏, I agree with a lot of this and thanks for sharing vsce show <ext_id>! When I have time, I'll look into optimizing Jupyter and our version lookups in general, as those are sometimes not reliable indeed.

[filiptronicek]

I'm for real tempted to make a different repo just for Jupyter because they really are nasty with versions 😄

[filiptronicek]

@xaberus sorry for the long wait. Could you please check if it's alright now? I have updated the extension at 2023.3.100.

[benz0li]

@xaberus sorry for the long wait. Could you please check if it's alright now? I have updated the extension at 2023.3.100.

@filiptronicek I can confirm that it works now. Thank you!

[xaberus]

@filiptronicek I think it works on my end. Had to reinstall it a couple of times, though. It seems VSCodium keeps the current version cached somewhere and just reinstalling always installs the cached version. What I did was to uninstall it from VSCodium and manually install the VSIX from Open-VSX...

[filiptronicek]

Thank you both!