Pyright resolution failing again

[sgtlaggy]

Still seems to be due to the package's id, ms-pyright.pyright, not matching the package's name from its package.json, vsocde-pyright, so resolveVersion always returns undefined.
This is sortof a followup to #588, where this problem was mentioned.

[filiptronicek]

Hi again, @sgtlaggy 👋, thanks for reaching out. It seems that the ID mismatch is more problematic then I initially thought because the renaming happens at the packaging step. This means that we cannot get the version to build from, since we always check that we're getting the correct extension by getting its ID like this (in Pyright's case):

1. We clone the repo
2. We checkout to the tag that corresponds to the latest release in the Microsoft Marketplace (1.1.263)
3. We check that if we go to the package.json, the ID matches the one we expect - so that we don't publish another extension by mistake
4. We publish from that resolved tag

Sadly, the 3rd step fails here, since the manifest's ID does not match the actual published extension's ID. Not sure how to tackle this other than hard-coding this extension into https://github.com/open-vsx/publish-extensions/blob/master/lib/resolveExtension.js :/.

[sgtlaggy]

The prepackage step replaces the name in the package.json with just pyright. Could the process be changed to run prepackage before that?

[filiptronicek]

Sadly not, because we must resolve the name before having the contents of the repo, so we cannot run the script before having access to it... I think I have a fix for this, though, although not perfect, I'll revert the change to the id in the extension's list which will make the resolution work, but always use the latest tag.

[sgtlaggy]

we must resolve the name before having the contents of the repo

But we already have the contents of the repo when checking the id against the name/publisher in package.json, because the package.json is in the repo.

[filiptronicek]

That is true, but by "contents" I mean the up-to-date contents according to the latest release. This is different since the id on the default branch could potentially differ from the one we want to release from.

[apollo13]

@filiptronicek I am running into a bug with pyright (microsoft/pyright#4416) and I think this is because it currently did build b3f57edde88e15f1adf7732f7ca7ee12f2bc0baf which is not the released revision:

https://github.com/open-vsx/publish-extensions/actions/runs/3852340403/jobs/6564382774#step:9:4680

I assume this is due to the ID missmatch? I guess as such pyright always (?) builds from the current main which can be broken. Is this assumption correct?

[filiptronicek]

Hi @apollo13,
this is indeed due to the ID mismatch, there are commits which should not be released under the newest release on Open VSX: microsoft/pyright@1.1.287...b3f57ed.

I'm going to look into this further, as this should not happen: releases happen via tags and therefore, even though the extension is "not published on the MS Marketplace"¹, it should only release based on the latest tag, https://github.com/microsoft/pyright/releases/tag/1.1.287.

Footnotes

1. it is, but the script thinks that it isn't because of the ID mismatch ↩

[apollo13]

Nice, that is great to hear. I went ahead and built the main branch of the extension and my bug is indeed there even on original Code -- so let's see if Microsoft accepts it as a bug now :)

[filiptronicek]

Hello again, @apollo13, from now on, the extension should always pick up the latest version from the Microsoft Marketplace by default. This does not sadly solve our little issue here.

For the issue microsoft/pyright#4416, we must re-publish the version of the extension. I requested a removal of this version in EclipseFdn/open-vsx.org#1532, which shouldn't take too long. After that is done, we can re-publish with the fixed extension package.

[apollo13]

Lovely, thanks! I have manually built the extension, so I am currently fine -- nevertheless thank you for your effort.