Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update extensions.json #842

Closed
wants to merge 1 commit into from
Closed

Update extensions.json #842

wants to merge 1 commit into from

Conversation

kinto0
Copy link

@kinto0 kinto0 commented Mar 20, 2025

  • I have read the note above about PRs contributing or fixing extensions
  • I have tried reaching out to the extension maintainers about publishing this extension to Open VSX (if not, please create an issue in the extension's repo using this template).
  • This extension has an OSI-approved OSS license (we don't accept proprietary extensions in this repository)

Description

Per suggestion here, we would like our vscode extension available here.

add pyrefly to open vsx registry
per suggestion [here](facebook/pyre-check#975 (comment))
facebook-github-bot pushed a commit to facebook/pyrefly that referenced this pull request Mar 21, 2025
Summary:
This diff adds a deploy_extensions github action which will deploy the extension on any changes to `pyre2/version.bzl`. This diff also switches the build action to use the version in `pyre2/version.bzl` so the extension version should always match the language server version in the marketplace.

To manually update the extension, developers should update the version in version.bzl (see the doc comment).

The version in `package.json` is not relevant because the build_extension action builds a specific version (`npx vsce package <platform> <version>`). this command updates package.json locally but does not get committed (if we don't want it modified we can `--no-update-package-json` on `npx vsce package` but I don't think it matters). if we want this to always be up to date with pyre2/version.bzl I can do that (I don't know if it matters).

Users of the extension should generally be disabling auto update and selecting a specific version of the extension (matching their pypy version) if they want to stay in sync with an old version.
{F1976279886}

I also opened a PR [here](EclipseFdn/publish-extensions#842) in order to make it [available in the open VSX registry](facebook/pyre-check#975 (comment))

Reviewed By: stroxler

Differential Revision: D71577667

fbshipit-source-id: 74e28230cf5bb1c6a33d72ad4f74f710277dbd77
facebook-github-bot pushed a commit to facebook/pyre-check that referenced this pull request Mar 21, 2025
Summary:
This diff adds a deploy_extensions github action which will deploy the extension on any changes to `pyre2/version.bzl`. This diff also switches the build action to use the version in `pyre2/version.bzl` so the extension version should always match the language server version in the marketplace.

To manually update the extension, developers should update the version in version.bzl (see the doc comment).

The version in `package.json` is not relevant because the build_extension action builds a specific version (`npx vsce package <platform> <version>`). this command updates package.json locally but does not get committed (if we don't want it modified we can `--no-update-package-json` on `npx vsce package` but I don't think it matters). if we want this to always be up to date with pyre2/version.bzl I can do that (I don't know if it matters).

Users of the extension should generally be disabling auto update and selecting a specific version of the extension (matching their pypy version) if they want to stay in sync with an old version.
{F1976279886}

I also opened a PR [here](EclipseFdn/publish-extensions#842) in order to make it [available in the open VSX registry](#975 (comment))

Reviewed By: stroxler

Differential Revision: D71577667

fbshipit-source-id: 74e28230cf5bb1c6a33d72ad4f74f710277dbd77
@kinto0 kinto0 closed this Apr 1, 2025
@kinto0 kinto0 reopened this Apr 1, 2025
@filiptronicek
Copy link
Member

Hi @kinto0 👋, as per our contributing guidelines:

A goal of Open VSX is to have extension maintainers publish their extensions according to the documentation. The first step we recommend is to open an issue with the extension owner. If the extension owner is unresponsive for some time, this repo (publish-extensions) can be used as a temporary workaround to ensure the extension is published to Open VSX.

The above also includes owners, who should publish the extension from their respective repositories instead of this one, so that they own the publishing process from end to end and reduce the maintenance burden on this repository.

Let me know if you have any questions, happy to assist with setting up the pipeline on your end.

I also see that you already have a pipeline for publishing to the Microsoft Marketplace: https://github.com/facebook/pyre-check/blob/main/pyre2/.github/workflows/deploy_extension.yml. This is awesome, and means that setting up publishing to Open VSX (besides getting an access token as described in the Wiki article) should be as easy as using ovsx in the same fashion as vsce for publishing to https://open-vsx.org.

@kinto0 kinto0 deleted the patch-1 branch April 2, 2025 21:40
facebook-github-bot pushed a commit to facebook/pyrefly that referenced this pull request Apr 3, 2025
Summary:
[issue](facebook/pyre-check#975 (comment))

I mistakenly tried adding support from [this](EclipseFdn/publish-extensions#842 (comment)) repo. Instead we should be doing it ourselves.

Reviewed By: stroxler

Differential Revision: D72345263

fbshipit-source-id: 9f9084282048749dab5119caa0afdc8be663b885
facebook-github-bot pushed a commit to facebook/pyre-check that referenced this pull request Apr 4, 2025
Summary:
[issue](#975 (comment))

I mistakenly tried adding support from [this](EclipseFdn/publish-extensions#842 (comment)) repo. Instead we should be doing it ourselves.

Reviewed By: stroxler

Differential Revision: D72345263

fbshipit-source-id: 9f9084282048749dab5119caa0afdc8be663b885
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants