This release is a pre-release and may not be stable for production use.
magicproto
Import .proto files directly. No protoc, no generated _pb2.py files, no
build step:
import magicproto # installs the import hook
from magicproto.greet import hello_pb2, hello_pb2_grpc
req = hello_pb2.HelloRequest(name="world")
stub = hello_pb2_grpc.GreeterStub(channel)
magicproto.greet.hello_pb2 compiles greet/hello.proto (found on
MAGICPROTO_PATH / sys.path) at import time and synthesizes the module.
The dotted Python path mirrors the canonical proto path 1:1, so the import
name, the file location, and the descriptor name can never drift apart — the
classic grpc_tools "the generated import points at the wrong place" problem
cannot occur.
How it works
- A scoped
sys.meta_pathfinder claims names undermagicproto.(only). magicproto.greet.hello_pb2→ canonicalgreet/hello.proto, located on the include roots (theprotoc -Imodel:MAGICPROTO_PATHthensys.path).- The Rust extension (
magicproto._compiler, built on the pure-Rustprotoxcompiler) turns the.protointo a serializedFileDescriptorSet— the one thing the stockprotobufruntime can't do itself. - Those descriptors are registered through the stock
descriptor_pool.Default()+google.protobuf.internal.builder, i.e. the exact path a generated_pb2.pyuses, so the message classes are indistinguishable from generated ones. _pb2_grpcmodules are synthesized directly from the service descriptors.
See DESIGN.md for the full rationale, the multi-package namespacing model, and the limitations.
Where to put protos
Put
foo/bar.protowhere you'd wantfoo/bar.py, and import it asmagicproto.foo.bar_pb2.
A library ships its protos as package data inside its own package directory; the directory name namespaces them, so two installed libraries can't collide.
Build (development)
python -m venv --system-site-packages .venv
source .venv/bin/activate
maturin develop
python examples/demo.py
pytest
Status
Prototype. Reuses the stock protobuf runtime for messages; a production build
would route descriptor construction through a dedicated upb-backed runtime
instead. See DESIGN.md § Limitations.
Release files for magicproto 0.1.0a0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distributions (wheels)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| magicproto-0.1.0a0-cp39-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl | CPython 3.9 | abi3 | Linux glibc 2.17+ x86-64 | Details |
| magicproto-0.1.0a0-cp39-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl | CPython 3.9 | abi3 | Linux glibc 2.17+ ARM64 | Details |
Total release size: 1.8 MB
Release files / magicproto-0.1.0a0-cp39-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
| Download URL | magicproto-0.1.0a0-cp39-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl |
|---|---|
| Size | 958.4 kB |
| Tags | CPython 3.9 Linux glibc 2.17+ x86-64 abi3 |
|
SHA-256 checksum How to use checksums |
cf08b73eea984414ecb61dc1c87379309f1a3674520a482bdd53bd418f3764f6
|
|
BLAKE2b-256 checksum How to use checksums |
9f8609d76fe64da85b5943eb85ea0f132286b3c9dc3cc5d30f9eb4d9321ce399
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.13.5
|
Release files / magicproto-0.1.0a0-cp39-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
| Download URL | magicproto-0.1.0a0-cp39-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl |
|---|---|
| Size | 825.4 kB |
| Tags | CPython 3.9 Linux glibc 2.17+ ARM64 abi3 |
|
SHA-256 checksum How to use checksums |
e75dfcbb8fcd5e5238376c63f2eb5987ce8b650684480d1fd2ded5f30d0909b7
|
|
BLAKE2b-256 checksum How to use checksums |
3e160ea38ffdec3b74e23400b62dd26aeb457d896417f8a122fdcca586f66c3c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.13.5
|