python: fix bare cross-file imports in generated .pyi stubs#13
Merged
Conversation
protoc's pyi generator aliases same-package imports differently than its .py generator (_foo_pb2 vs foo__pb2), so protoletariat's rewriter - which matches whole import statements including the alias - leaves the pyi side as a bare `import foo_pb2 as _foo_pb2` while the .py sibling correctly gets `from . import foo_pb2 as foo__pb2`. A bare import only resolves when a top-level module of that name happens to exist, which it doesn't once installed as a package - so pyright and other static checkers can't resolve types across these files (car_server, vcsec, vehicle, universal_message under command/, three files under energy_device/), even though runtime behavior is unaffected since the .py files are correct. scripts/generate.sh now runs scripts/fix_pyi_imports.py after protol to patch any bare pyi import whose target is an actual sibling module.
Bre77
pushed a commit
to Teslemetry/python-tesla-fleet-api
that referenced
this pull request
Jul 22, 2026
0.5.0 fixes the generated .pyi cross-file import bug (Teslemetry/tesla-protocol#13) that broke pyright strict mode; pyright is now clean with no local suppressions needed.
Bre77
added a commit
to Teslemetry/python-tesla-fleet-api
that referenced
this pull request
Jul 22, 2026
* feat(proto): adopt tesla-protocol PyPI package as proto source Replace the vendored proto/ sources and generated tesla_fleet_api/tesla/ vehicle/proto/ modules with the published tesla-protocol package (Teslemetry/tesla-protocol, generated as tesla_protocol) - the API client already adopted the npm sibling package, so this brings the Python library onto the same shared, single source of truth. All imports now resolve from tesla_protocol.command.<module>_pb2 instead of the local vendored copies; tools/regenerate_protos.sh and createProto.sh are gone along with the generated files they produced. tesla-protocol requires protobuf<7,>=6.32.0 and stamps gencode 6.31.1, both compatible with Home Assistant core's protobuf==6.32.0 pin. tesla-protocol 0.4.0's generated .pyi stubs have an upstream bug (bare cross-file imports that don't resolve, unlike the correctly relative .py files) that breaks pyright strict mode on 14 lines in commands.py; fixed upstream in Teslemetry/tesla-protocol#13. Left unsuppressed here since masking it with local pyright ignores would hide a real upstream defect - bump the tesla-protocol floor once a release with that fix ships. * chore(deps): bump tesla-protocol to >=0.5.0 0.5.0 fixes the generated .pyi cross-file import bug (Teslemetry/tesla-protocol#13) that broke pyright strict mode; pyright is now clean with no local suppressions needed. * Bump version to 1.7.7 * no-mistakes(review): Restore legacy protobuf import compatibility * no-mistakes(document): Refresh protobuf documentation and references --------- Co-authored-by: firstmate crewmate <crewmate@firstmate.local>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
protoc's pyi generator aliases same-package imports differently than its
.pygenerator (_foo_pb2vsfoo__pb2), so protoletariat's rewriter - which matches whole import statements including the alias - leaves the pyi side as a bareimport foo_pb2 as _foo_pb2while the.pysibling correctly gets rewritten tofrom . import foo_pb2 as foo__pb2. A bare import only resolves when a top-level module of that name exists, which it doesn't once installed as a package, so pyright (and other static checkers) can't resolve types across these files even though runtime behavior is unaffected.Affected:
car_server_pb2.pyi,universal_message_pb2.pyi,vcsec_pb2.pyi,vehicle_pb2.pyiundercommand/, plusauthorization_api_pb2.pyi,common_api_pb2.pyi,transport_pb2.pyiunderenergy_device/.Found downstream in
python-tesla-fleet-apiwhile migrating it onto this package - pyright strict mode broke onRoutableMessage.signature_data,VehicleData.vehicleData, etc.scripts/generate.shnow runs a smallscripts/fix_pyi_imports.pypass afterprotolto patch any remaining bare pyi import whose target is an actual sibling module, so regeneration won't reintroduce this.