Python proto generation produces broken absolute imports

[nicklasl]

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