Add gdscript and godot package definitions - #133
Conversation
|
Two unversioned definitions built from godotengine/godot-docs at ref
stable (Godot 4.7):
gdscript/gdscript docs_path tutorials/scripting/gdscript
9 files, 129 sections, 60,921 tokens, 0 skipped
godot/godot whole repo
1,604 files, 14,488 sections, 8,136,611 tokens, 0 skipped
Built at godot-docs 6d86d7c7f3b8f4f56c71e113022d72fe80b2c84d and
reproduced independently three times across node 22/24 and context
1.2.4/1.2.5 with identical file, section and token counts.
gdscript is scoped to the GDScript subtree rather than to
tutorials/scripting because the wider path is 40% C# by section count
(208 of 515), and C# wins the ranking for the most common lookups --
under the product's own bm25 weights, none of the top five results for
"signal" is GDScript. Git sources have no exclude_paths, so narrowing
the path is the only way to get a GDScript package that returns
GDScript. Everything the narrow path omits, including the @GDscript and
@globalscope built-ins in classes/, is covered by the godot package, and
each description points at the other.
godot-docs is licensed CC-BY 3.0 Unported.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
32983ce to
3a87423
Compare
moshest
left a comment
There was a problem hiding this comment.
Thanks for this — the descriptions are unusually careful, and I checked the claims in them rather than taking them at face value. Everything factual holds up:
ref: stableexists ongodotengine/godot-docs.docs_path: tutorials/scripting/gdscriptexists and contains exactly the 9 files your description advertises (basics, advanced, exports, static typing, style guide, warning system, doc comments, format string).- The class reference is committed here —
classes/has 1079.rstfiles includingclass_@gdscript.rstandclass_@globalscope.rst. Worth stating explicitly because the similar-looking systemd case in #116 fails precisely here (its man pages are generated at build time, not committed), so "official docs repo" doesn't imply the reference is actually in it. Yours is.
I also built both definitions locally, since CI doesn't cover registry YAML:
| package | sections | tokens |
|---|---|---|
gdscript |
129 | 60,921 |
godot |
14,488 | 8,136,608 |
Both build successfully.
One thing worth changing before merge
godot has no docs_path, so it indexes the whole repository — which includes tutorials/scripting/gdscript/, the entire contents of the gdscript package. The two descriptions tell readers to use one for syntax and the other for engine APIs, but as written godot is a superset and those 9 files get indexed twice.
The schema already supports the fix (registry/java/java.yaml uses exclude_paths):
source:
type: git
url: https://github.com/godotengine/godot-docs
ref: stable
exclude_paths:
- "tutorials/scripting/gdscript/**"That makes the split you describe actually true.
Two notes for the maintainer, not asks of you
- Size. 8.1M tokens is by far the largest definition here — 133× your
gdscriptpackage, and ~37× the systemd prototype measured in #116. I found no documented size ceiling in the registry code, so this isn't a rule violation, just worth a deliberate decision rather than an accidental one. - No CI ran on this PR (zero check runs), and separately
ci.ymldoesn't validateregistry/*.yamlat all — it lints/builds/tests the TS packages only. A definition with a wrongrefordocs_pathwould pass review and first fail in the 06:00 nightly. That's a gap in our tooling, not in your contribution.
Not approving since the exclude_paths question is the author's call, but the definitions themselves are sound and I'm happy to see them land.
Generated by Claude Code
ci.yml lints, builds and tests the TypeScript packages; nothing there reads registry/*.yaml. A definition naming a branch or docs_path that does not exist passed review and CI unchallenged, then failed at 06:00 UTC in the nightly registry-update, long after the PR that introduced it was merged. #133 made it concrete: two new definitions arrived with zero check runs. This builds the definitions a PR adds or modifies, on the PR, using the existing test-registry CLI. Only changed ones, so cost tracks the diff rather than the 113-definition registry. Proven with a deliberate probe rather than assumed: a definition pointing at a nonexistent branch triggered the workflow and failed it with "Remote branch this-branch-does-not-exist-xyz not found in upstream origin", exit 1. The probe and its removal are kept as separate commits so the evidence stays in history. A nonexistent docs_path also exits 1 rather than producing an empty package, which was the failure mode worth ruling out.
|
Correcting my review above: the I verified it in the code rather than leaving it as competing claims — Your routing rationale answers the overlap point too, and with measurements I didn't have: C# taking 40% of Adding Two things on CI, since this PR has never had any:
For what it's worth, I built both definitions locally before any of that: Generated by Claude Code |
Add GDScript and Godot Engine package definitions
Adds two registry definitions built from
godotengine/godot-docs:registry/gdscript/gdscript.yaml— the GDScript languageregistry/godot/godot.yaml— the Godot engine: full class reference + tutorialsBoth use the self-named-directory convention the registry README prescribes for projects
not distributed by a package manager, alongside
registry/python/python.yamlandregistry/java/java.yaml.Build results
Built at
godot-docscommit6d86d7c7f3b8f4f56c71e113022d72fe80b2c84d(branch
stable, 2026-08-05, = Godot 4.7):gdscript/gdscripttutorials/scripting/gdscriptgodot/godotZero skipped files in both.
.rstis already a supported input format, so no new parsingis required. Both definitions were validated by running the repository's own
loadDefinition()andlistDefinitions()— including the whole-tree scan, since one baddefinition fails the nightly publish for every other package.
Why
gdscriptis scoped narrowlytutorials/scripting/gdscriptyields 129 sections, which is below the README's "a fewhundred" guideline, so it is worth explaining why that is deliberate rather than a
misconfigured
docs_path.The obvious wider path,
tutorials/scripting, yields 515 sections — but they break down as:c_sharp/gdscript/scripting/rootcpp/debug/C# is the largest block in what would ship as a GDScript package, and it wins the most
important queries. Top-5 results from that build, ranked exactly as
search.tsranks them(
bm25(chunks_fts, 5.0, 10.0, 1.0) * -1,ORDER BY score DESC, afterbuildQuery()):signal→c_sharp_signals,how_to_read_the_godot_api,cross_language_scripting,c_sharp_signals,c_sharp_signals— none of the five is GDScriptawait→c_sharp_differencesat fix(cli): accept package name with version suffix in remove command #1lambda→ one GDScript hit, then four C# pagesexport→ C# at fix: skip prerelease versions when detecting latest stable tag #2 and docs: update README to reference Next.js 16 #3Since git sources have no
exclude_paths(only zip sources do), the C# and C++ subtreescannot be pruned from
tutorials/scripting. Narrowing the path is the only way to get aGDScript package that returns GDScript. The same queries against the narrow build return
gdscript_basics: Signals×3,gdscript_exports×4, andstatic_typing×4 — every top hiton target.
One further consequence of the narrow scope, stated plainly because a reviewer will hit it:
when a query matches a built-in function name, the
gdscriptpackage returnslexically-plausible but topically-wrong results rather than nothing, because those words
appear incidentally in tutorial prose.
gdscriptpackage returnspreloadgdscript_basics: Keywords,Classesclasses/class_@gdscript.rstrangegdscript_exports: Limiting editor input rangesclasses/class_@gdscript.rstpush_errorstatic_typing: How to use static typingclasses/class_@globalscope.rstget_nodegdscript_styleguide: Static typingclasses/class_node.rstinstclasses/class_@gdscript.rstAll five resolve correctly in the
godotpackage. This is intended routing rather than adefect —
classes/is unreachable from any tutorial path — but it is why thegdscriptdescription names the built-ins explicitly and points at the
godotpackage for them,instead of only mentioning "engine APIs".
Everything the narrow path omits (autoloads, resources, groups, the scene tree,
overridable functions, debugging, multiplayer RPC) is covered by the
godotpackage,which also carries
class_@gdscript.rstandclass_@globalscope.rst— the built-infunctions (
preload,load,assert,range,str) that live inclasses/and areunreachable from any tutorial path. Each definition's
descriptionpoints at the other soan agent can route between them.
Notes for reviewers
ref: stable—godot-docshas no git tags at all, and no ReadTheDocs htmlziparchives are published (all such URLs 404), so neither the tag-pattern nor the
versioned-by-zip shape applies. The
stablebranch tracks the current Godot release andadvances on its own, and
source_commitis populated so skip-if-unchanged works.doc_pathvalues with backslashes(
tutorials\scripting\...). That is a local artifact ofreadLocalDocsFileson Windows,not a problem with these definitions; Linux CI produces forward slashes. Please don't
"fix" the YAML paths for it.
listDefinitions()on Windows throwsDefinition name "@apollo/client" doesn't match filename "@apollo\client.yaml", becauseloadDefinition()compares arelative()path against a/-joined name. It reproduceson
mainwith these definitions removed, so it is not caused by this PR and does notaffect Linux CI. Flagging it rather than fixing it here to keep this PR to one concern; a
split(sep).join("/")on the derived name would resolve it.godotis 48.03 MB, against the client's 512 MBDEFAULT_MAX_DOWNLOAD_BYTESand fetched on demand. A
classes-only variant was measured (10,960 sections, 38.8 MB);it saves 9 MB and loses every tutorial, so it was rejected.
Attribution
godotengine/godot-docsis licensed CC-BY 3.0 Unported (verified from itsLICENSE.txt). Both definitions carryrepository:pointing at the upstream repo.