spotify / spotify/confidence-resolver
Python proto generation produces broken absolute imports
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 16
- Forks
- 14
- Avg merge
- 2d 7m
- Merged PRs (30d)
- 40
Description
Problem
Running make proto in openfeature-provider/python/ generates Python protobuf files with absolute imports like:
from confidence.flags.resolver.v1 import types_pb2
But the package structure puts these files under src/confidence/proto/confidence/flags/resolver/v1/, so the correct absolute import would be:
from confidence.proto.confidence.flags.resolver.v1 import types_pb2
The absolute path confidence.flags doesn't exist as a Python module — only confidence.proto.confidence.flags does.
Root Cause
The make proto command uses:
$(PYTHON) -m grpc_tools.protoc \
-I../proto \
--python_out=src/confidence/proto \
--grpc_python_out=src/confidence/proto \
../proto/confidence/flags/resolver/v1/*.proto \
../proto/confidence/wasm/*.proto
Protoc derives Python import paths from the proto package structure (confidence.flags.resolver.v1), but the output directory (src/confidence/proto) adds a proto.confidence prefix that protoc doesn't account for. The mismatch means protoc's absolute imports resolve to non-existent modules.
Current Workaround
The proto files checked into main were manually adjusted to use relative imports (from . import types_pb2), which work regardless of the package nesting. However, regenerating with make proto overwrites these with broken absolute imports.
Possible Fixes
- Post-process — add a sed step after
make prototo rewrite absolute imports to relative - Restructure output — change
--python_out=src/so protoc's absolute import paths align with the actual package layout (but mixes proto files with application code) - Restructure protos — change the proto package names or Python package structure to align
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect the make proto recipe in openfeature-provider/python and compare its generated imports with the checked-in files under that package. Reproduce the issue with make proto, then establish an approach that makes regenerated imports resolve under the package layout and verify both generation and Python imports.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100