Experminental PR for adding metadata to protobufs#905
Conversation
|
The latest Buf updates on your PR. Results from workflow pull-request / build (pull_request).
|
|
Just noting here for good measure, the following patch is needed to make this work in python: diff --git a/bin/regen-protobufs.sh b/bin/regen-protobufs.sh
index 23def7b..c48b856 100755
--- a/bin/regen-protobufs.sh
+++ b/bin/regen-protobufs.sh
@@ -45,6 +45,8 @@ $SEDCMD 's/^import "meshtastic\//import "meshtastic\/protobuf\//' "${INDIR}/"*.p
$SEDCMD 's/^import "nanopb.proto"/import "meshtastic\/protobuf\/nanopb.proto"/' "${INDIR}/"*.proto
+$SEDCMD 's/\(meshtastic.config_field\)/(meshtastic.protobuf.config_field)/' "${INDIR}/"*.proto
+
# Generate the python files
./nanopb-0.4.8/generator-bin/protoc -I=$TMPDIR/in --python_out "${OUTDIR}" "--mypy_out=${PYIDIR}" $INDIR/*.protoonce done, the following procedure gets access to the values: from meshtastic.protobuf import config_pb2,field_metadata_pb2
field_descriptor = config_pb2.Config.PositionConfig.DESCRIPTOR.fields_by_name['rx_gpio']
options = field_descriptor.GetOptions()
options.Extensions[field_metadata_pb2.config_field].diy_only # returns True |
Adds build-time codegen that auto-generates a ConfigFieldMetadataRegistry from (meshtastic.config_field) annotations in .proto files. - New FieldMetadataSchemaHandler in build-logic walks all message fields - Emits a static Kotlin registry mapping (messageType, fieldTag) → metadata - Zero runtime cost, no wire-schema dep in app binary - Adding annotations to new fields requires no code changes Companion to: meshtastic/protobufs#905
Adds build-time codegen that auto-generates a ConfigFieldMetadataRegistry from (meshtastic.config_field) annotations in .proto files. - New FieldMetadataSchemaHandler in build-logic walks all message fields - Emits a static Kotlin registry mapping (messageType, fieldTag) → metadata - Zero runtime cost, no wire-schema dep in app binary - Adding annotations to new fields requires no code changes Companion to: meshtastic/protobufs#905
Adds build-time codegen that auto-generates a ConfigFieldMetadataRegistry from (meshtastic.config_field) annotations in .proto files. - New FieldMetadataSchemaHandler in build-logic walks all message fields - Emits a static Kotlin registry mapping (messageType, fieldTag) → metadata - Zero runtime cost, no wire-schema dep in app binary - Adding annotations to new fields requires no code changes Companion to: meshtastic/protobufs#905
Replace the ConfigFieldMetadata message wrapper with a direct
scalar bool extension on FieldOptions. This allows Wire 6's native
emitAppliedOptions to generate @DiyOnlyOption annotations without
a custom SchemaHandler, and simplifies access for all downstream
clients (Swift, Python, Go).
Usage: [(meshtastic.diy_only) = true] instead of
[(meshtastic.config_field).diy_only = true]
143d8c0 to
fc5a1a2
Compare
|
Updated to use scalars: Proto Simplification:
|
| Client | Tool | Impact |
|---|---|---|
| Android | Wire 6.2 | ✅ Wire natively emits @DiyOnlyOption(true) on generated fields |
| Apple | protoc-gen-swift | ✅ generates var diyOnly: Bool extension on FieldOptions directly |
| Python | protoc | ✅ Extensions[diy_only] returns bool directly instead of unwrapping a message |
| Firmware | nanopb | ✅ No impact — nanopb ignores custom options |
Extensibility
Future metadata (e.g. admin_only, min_value) → just add more scalar extensions in the 51000–51999 range. No shared wrapper message to evolve.
…hemaHandler The upstream proto (meshtastic/protobufs#905) has been simplified to use a scalar bool extension instead of a message wrapper: [(meshtastic.diy_only) = true] Wire 6's emitAppliedOptions now natively generates @DiyOnlyOption(true) annotations on fields, eliminating the need for our custom FieldMetadataSchemaHandler. Changes: - Delete FieldMetadataSchemaHandler.kt (~200 LOC) - Remove wire-schema dependency from build-logic - Remove custom {} handler block from core:proto build - Add emitAppliedOptions = true to Wire kotlin {} config - Update FieldMetadataDemo to demonstrate the native annotation - Bump protobufs submodule to metadata-experiment branch
|
Superseded by #952 — generalizes this experiment into a structured |
Introduces a structured (meshtastic.field_metadata) custom field option and build-time generators that expose it as reflection-free static accessors in every consumer language: KMP/Wire (Wire SchemaHandler in packages/kmp/buildSrc) and C/Python/TypeScript/Rust/Swift (the tools/protoc-gen-fieldmeta plugin). The TS target is wired into buf.gen.yaml and re-exported from mod.ts as FieldMeta. Generalizes the #905 experiment: one extensible FieldMetadata message carried in a single FieldOptions extension, so adding an attribute is a schema-only change (scalar-only, enforced at generation time) with no new extension number and no generator changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Introduces a structured (meshtastic.field_metadata) custom field option and build-time generators that expose it as reflection-free static accessors in every consumer language: KMP/Wire (Wire SchemaHandler in packages/kmp/buildSrc) and C/Python/TypeScript/Rust/Swift (the tools/protoc-gen-fieldmeta plugin). The TS target is wired into buf.gen.yaml and re-exported from mod.ts as FieldMeta. Generalizes the #905 experiment: one extensible FieldMetadata message carried in a single FieldOptions extension, so adding an attribute is a schema-only change (scalar-only, enforced at generation time) with no new extension number and no generator changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Can we set devices to DIY vs fully-assembled, and then hide the diy-only options in the apps when connected to a pre-assembled board? Let's find out!