combine plugins multiple sources to simplify UI#25
Conversation
williballenthin
left a comment
There was a problem hiding this comment.
The direction of this PR is fine, but some changes are needed.
- there are some oversights that need to be fixed, including adding a second copy of the plugin repo. And, LLM-generated text that doesn't seem quite right (exactly 12 categories is a strict output requirement?).
- some of the presentation-layer data should move into the web UI, and not be stored in this repo.
- we should consider removing the legacy plugins from plugins.hex-rays.com, which will simplify the code, including removing quite a bit from this PR.
I realize that for (2) and (3) you're following the assignment, but I think we (including @pal-hexrays if necessary) should realign rather than push this through.
scripts/merge_plugins.py
Outdated
| # | ||
| # Inputs: | ||
| # A api-plugins.json All plugins from the Hex-Rays API (one-time dump) | ||
| # B hcli-plugins.json HCLI-indexed plugins (plugin-repository.json from GitHub) |
There was a problem hiding this comment.
this should be plugin-repository.json
There was a problem hiding this comment.
Done. At the beginning I saw that they are not identical and I was afraid to update plugin-repository.json because I was thinking that maybe other services are counting on it.
There was a problem hiding this comment.
right, plugin-repository.json is auto-generated periodically, and shouldn't be modified directly.
github-metadata.json
Outdated
There was a problem hiding this comment.
i think this should be generated on demand, rather than committed, since it changes so frequently. thoughts?
There was a problem hiding this comment.
added fetch-metadata and merge-plugins depends on fetch-metadata, so it always gets fresh data automatically.
There was a problem hiding this comment.
this might be outside the scope of this PR, but I think we should remove the legacy plugins from plugins.hex-rays.com. at this point we have ~100 HCLI-compatible plugins, so the index is sufficiently populated and the ecosystem is healthy. removing the legacy plugins will simplify code in many places, as well as reduce confusion about which plugins show up where.
@pal-hexrays @hx-geoffrey thoughts?
There was a problem hiding this comment.
imho, this presentation layer information belongs in the web user interface codebase, not here. which icons are used for each category and how they are translated from ID -> human reasonable name is the domain of the UI, not of the backend json data.
scripts/merge_plugins.py
Outdated
| # | ||
| # Outputs: | ||
| # plugins-combined.json All plugins (HCLI + legacy), enriched and ready for the UI | ||
| # categories.json 12 category definitions with pluginCount |
There was a problem hiding this comment.
is "12" part of the API contract? or simply a snapshot of the current count? this reads like LLM-authored content and i can't tell the intent.
There was a problem hiding this comment.
Comment updated. 12 was a snapshot of the current count but if I got it right categories will stay the same in future.
|
also, this should have been first: thank you @florinnania! I'm happy we're moving in this direction and you're helping to make it so :-) |
|
|
||
|
|
||
| fetch-metadata: | ||
| curl -sSfL -o github-metadata.json https://hexrayssa.github.io/plugin-repository/plugins/github.com/repositories-metadata.json |
There was a problem hiding this comment.
the step collect-starts just before this emits repositories-metadata.json so lets just use that?
There was a problem hiding this comment.
why is this file modified?
Simplify Plugin Repository UI — Eliminate the API
The UI currently does a big merge at runtime in
DataMerger.js— fetches from multiple sources, transforms, deduplicates, enriches. This PR moves all of that into a Python build script that runs offline and outputs a single ready-to-use JSON. The UI just loads it. No API, no runtime merging.The inputs
api-plugins.jsonida-plugin.json)plugin-repository.jsonon GitHub (auto-generated)tags.jsonon GitHubPlus GitHub metadata (
repositories-metadata.json— stars, forks, dates) and categories (currently from the API, you'll create acategories.json).Important: C (
tags.jsonon GitHub) is incomplete — it only hasfavouriteandplugin_contest_2024. The full tag set (contest years 2016-2024, placementsfirst_place/second_place/third_place,award_winning, etc.) only exists in A (the API). So the build script gets tags from both A and C, merged.What the script does
Basically what
DataMerger.jsdoes today, but at build time:plugin_manager_readyplugins-combined.jsonready for the UI