Repository navigation
Reexamine bindgen prototype for CLI-wrapping providers #215
Description
Context
The prototype/bindgen/ directory contains a prototype code generator that wraps CLI tools (docker, git, npm) as Starlark providers. It parses command schemas and generates receiver code with method bridges.
Phase 5a updated the prototype's template to replace MakeAttr with starlark.NewBuiltin, keeping it in sync with the pkg/op API. But the prototype hasn't been evaluated against the current provider architecture (reflection-based dispatch, RegisterReflectedActions, typed provider references).
Questions to resolve
- Is bindgen still the right approach for CLI-wrapping providers, or should they use the same reflection-based codegen pipeline (
star devlore actions generate) that all other providers use? - What would a bindgen-generated provider look like under the current architecture (announce/init,
var Provider,MethodParams, planned/immediate receivers)? - Are docker, git, and npm still the target CLIs? Are there others?
- Should bindgen output be a provider package under
pkg/op/provider/or remain separate?
Files
prototype/bindgen/internal/codegen.go— Go template for generated receiversprototype/bindgen/internal/cobra/extractor_test.go— schema extraction testsprototype/bindgen/internal/schema_test.go— schema parsing tests
Activity
David-Noble-at-work commentedon Aug 12, 2026
Closing with the answer and the record, per docs/plans/remove-bindgen-prototype.md — the prototype is removed by f6ae089 (PR forthcoming;
git show f6ae08993e52ac3807f18180e34979922081ad27^:prototype/bindgen/internal/cobra/README.mdretrieves the full analysis, or any other file likewise).What it was
A binding generator for wrapping cobra-based CLIs as Starlark providers: an AST extractor enumerated commands and flags, and a generator emitted receiver scaffolding. One recorded run (2026-01-11, its creation date): 144 commands and 272 flags from docker-cli v27.4.1, producing 4,124 lines of generated Go.
Why the approach ends here
Its own README's end-to-end analysis is the verdict. AST extraction yields syntax without semantics: ~6 of ~100 flags captured for
run, no positional arguments, and wrong invocation forms (docker container_runfordocker container run). The comparison table showed 15 hand-written commands production-ready against 144 generated ones each needing human refinement — extraction saved the cheap part and kept the expensive part. That is a ceiling, not a bug list: the missing information is not in the AST.What superseded it
Both of this issue's open questions resolved against bindgen. Providers converged on the reflection-based codegen pipeline (
star devlore actions generate); and generate-from-vendor-docs became the AI authoring direction —lore onboardoperationally, the licensing draft's authoring-CAG strategically — which obtains the semantics that source extraction structurally cannot.State at deletion
The tree was dead by every mechanical measure: the extractor, its test, and
cmd/main.goall carried//go:build ignore; the extractor importedinternal/bindgen, which does not exist; nothing imported any package in the tree; andgo mod tidyhad already droppedgolang.org/x/tools, its only distinctive dependency.Ruling 2026-08-12: bindgen will not work well enough; removed whole. History keeps it.
chore: remove the bindgen prototype (#386)