spotify / spotify/confidence-resolver

Python proto generation produces broken absolute imports

Open
#333 0 comments 0 reactions 0 assignees View on GitHub

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

  1. Post-process — add a sed step after make proto to rewrite absolute imports to relative
  2. 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)
  3. Restructure protos — change the proto package names or Python package structure to align

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.