Protocol Buffers (protobuf) — Administrator & Developer Guide

1. Architecture Overview

Protocol Buffers is Google's language-neutral, platform-neutral serialization framework consisting of three major architectural layers: a schema definition language (the .proto format), a compiler (protoc) that generates language-specific code from schemas, and per-language runtime libraries that provide serialization, deserialization, reflection, and message manipulation.

The project is organized as a multi-language monorepo with a shared C++ core, a micro protobuf C library (upb) used as the high-performance backend for several language runtimes, and individual language-specific implementations that may use native code, upb, or the C++ runtime as their backend.

                          .proto files
                              │
                         ┌────▼────┐
                         │  protoc  │ (C++ compiler)
                         └────┬────┘
            ┌─────┬─────┬────┼────┬─────┬─────┬─────┐
            ▼     ▼     ▼    ▼    ▼     ▼     ▼     ▼
          C++   Java  Python C#  Ruby  PHP   Rust   Go*
          │      │     │     │    │     │     │      │
          ▼      ▼     ▼     ▼    ▼     ▼     ▼      ▼
       libprotobuf  protobuf  Google. google- PHP   protobuf
       (C++ lib)    -java     Protobuf protobuf      (crate)
                     │         (NuGet) (gem)   │      │
                     │                  │      │      │
                     ▼                  ▼      ▼      ▼
                  JVM runtime      upb (C)  upb (C)  upb/C++
                                  backend   backend  backend

  * Go runtime lives in separate repo: protobuf-go

Note

The Go, Dart, and JavaScript protobuf implementations live in separate repositories (protobuf-go, dart-lang/protobuf, protobuf-javascript). This repository contains C++, Java, Python, C#, Ruby, PHP, Kotlin, Objective-C, and Rust implementations.

Component Inventory

Technology Stack

Data Flow: Protobuf Compilation and Serialization

1. Schema Definition
   developer writes .proto file
        │
2. Code Generation
   protoc --<lang>_out=./gen schema.proto
   protoc reads .proto → builds FileDescriptor → invokes language-specific CodeGenerator
        │
3. Compilation
   language compiler compiles generated code + runtime library
        │
4. Serialization (at runtime)
   app creates message → sets fields → SerializeToString()
   message → field-by-field encoding → varint tags + wire-format values → byte stream
        │
5. Deserialization
   byte stream → ParseFromString() → decoded message object
   parser reads tag → identifies field number + wire type → decodes value → populates message

Wire Format

The binary wire format uses field tags (field number + wire type) followed by the encoded value:

Tag encoding: (field_number << 3) | wire_type

2. System Requirements

Building from Source

Runtime Requirements by Language

Important

For Rust, the protoc binary version must exactly match the protobuf crate version. If you're using Rust protobuf x.y.z, you need protoc y.z. This is enforced by the codegen crate.

3. Configuration Reference

protoc Compiler Flags

Language-specific sub-options (passed via --<lang>_opt=):

Proto File Options

Environment Variables

Warning

Setting PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION to an unsupported value raises ValueError at import time. Only python, cpp, and upb are valid.

Editions Feature Flags

The Editions system replaces proto2/proto3 syntax with per-feature configuration. Edition 2023 is the first stable edition.

4. Deployment & Scaling

Building protoc from Source (Bazel)

git clone https://github.com/protocolbuffers/protobuf.git
cd protobuf
git submodule update --init --recursive

# Build protoc
bazel build //:protoc

# Build all C++ libraries
bazel build //src/google/protobuf:protobuf

# Build Java artifacts
bazel build //java/core:core

# Run all tests
bazel test //...

Building protoc from Source (CMake)

git clone https://github.com/protocolbuffers/protobuf.git
cd protobuf
git submodule update --init --recursive

cmake -S . -B build \
  -DCMAKE_BUILD_TYPE=Release \
  -Dprotobuf_BUILD_TESTS=OFF \
  -Dprotobuf_ABSL_PROVIDER=module

cmake --build build --parallel $(nproc)
cmake --install build --prefix /usr/local

Tip

Use -Dprotobuf_BUILD_TESTS=OFF to skip building tests and significantly reduce build time. Use -Dprotobuf_ABSL_PROVIDER=module to build abseil-cpp from the bundled submodule.

CMake Integration in Downstream Projects

find_package(Protobuf REQUIRED)

protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS person.proto)
add_executable(myapp main.cpp ${PROTO_SRCS})
target_link_libraries(myapp protobuf::libprotobuf)

Building Java Artifacts

cd java
mvn clean install -DskipTests

The Java build produces these Maven artifacts:

Building Python Package

cd python
python setup.py build
pip install .

Building C# Package

cd csharp
dotnet restore src/Google.Protobuf/Google.Protobuf.csproj
dotnet pack --no-restore -c Release src/Google.Protobuf.sln -p:ContinuousIntegrationBuild=true

Note

The C# build script sets DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true and DOTNET_CLI_TELEMETRY_OPTOUT=true to disable telemetry and first-run behavior.

Building Ruby Gem

cd ruby
bundle install
rake compile
rake build

Ruby uses rake-compiler for building the C extension and supports cross-compilation via rake-compiler-dock.

Building PHP Extension

cd php
# Pure PHP (via Composer)
composer install

# C extension
cd ext/google/protobuf
phpize
./configure
make
make install

Building Rust Crates

The Rust implementation is published as multiple crates:

cd rust/release_crates
cargo build --workspace

Release Process

Pre-built binaries and packages are published via:

5. Operations

Conformance Testing

The conformance testing framework validates that all language implementations produce identical serialization/deserialization behavior:

# Build and run conformance tests
bazel test //conformance/...

The conformance test runner (conformance/conformance_test_runner) communicates with language-specific test harnesses via stdin/stdout using length-prefixed binary messages. Each request specifies an input format (binary, JSON, text), a message type, and a desired output format. The harness serializes/deserializes and returns the result.

Supported conformance harnesses:

Failure list management:

Known failures are tracked in failure list files. The conformance/update_failure_list.py tool manages these lists:

python conformance/update_failure_list.py failure_list.txt --add "TestName" --remove "FixedTest"

Tip

Run conformance tests after any change to serialization logic to catch cross-language regressions early. The conformance suite covers proto2, proto3, edition2023, and edition-unstable message types.

Compatibility Testing

The compatibility/ directory contains smoke tests that verify backward compatibility with previous protobuf versions (v3.0.0, v3.8.0, v3.11.0, v3.19.0, v3.20.0, v3.25.0, v25.8, v26.0, v32.1). These tests ensure that generated code from older protoc versions can be compiled against the current runtime.

Version Compatibility Matrix

Important

Always match the protoc compiler version with the runtime library version. Cross-version combinations may produce subtle bugs or compilation errors.

Benchmark Suite

# Run benchmarks
bazel run //benchmarks:benchmark -- --benchmark_filter=".*"

The benchmark suite measures serialization and deserialization performance across message sizes and complexities.

6. Performance

upb: The Micro Protobuf Library

upb is a small, fast C library for parsing and serializing protobuf messages. It serves as the backend for several language runtimes:

upb architecture:

Note

upb uses arena allocation exclusively — all message memory is allocated from arenas and freed in bulk when the arena is destroyed. This provides excellent performance for typical protobuf usage patterns (create, populate, serialize, discard) but means individual message fields cannot be freed independently.

Performance Considerations

Serialization size optimization:

• Use sint32/sint64 for frequently negative values (ZigZag encoding)
• Use fixed32/fixed64 for values typically > 2^28 / 2^56
• Assign field numbers 1–15 to frequently set fields (1-byte tag)
• Use packed encoding for repeated scalars (default in proto3)

Runtime performance:

• Python: ensure the upb backend is active (default); pure Python is 10–50x slower
• Java: the full runtime includes reflection and text format; use javalite for size-sensitive applications
• C++: enable arena allocation (option cc_enable_arenas = true) for batch allocation patterns
• Rust: choose between upb_kernel (C backend, smaller binary) and cpp_kernel (C++ backend, feature parity)

Wire format efficiency compared to alternatives:

7. Security

Input Validation

Protobuf parsers perform structural validation of incoming data but do not validate application-level semantics:

Caution

Always set message size limits when parsing untrusted input. The default limit is 64 MB, but a maliciously crafted message can consume excessive memory (see GitHub issue #27104 — OOM in packed field decoders).

Known Vulnerabilities in Current Source

Based on open GitHub issues:

Security Best Practices

1. Set message size limits — use CodedInputStream::SetTotalBytesLimit() (C++) or CodedInputStream.setSizeLimit() (Java)
2. Set recursion depth limits — the default is 100 levels; reduce for untrusted input
3. Validate after parsing — protobuf doesn't enforce business rules; validate field values in application code
4. Don't expose descriptors — reflection APIs can reveal schema details; avoid exposing them in production
5. Use deterministic serialization for signing — default serialization is non-deterministic for map fields
6. Sanitize text format input — text format parsing is more permissive than binary; treat text input as untrusted

Warning

Protobuf's binary format provides no authentication, encryption, or integrity checking. Use TLS for transport security and sign/encrypt at the application level if needed.

UTF-8 Validation

Proto3 requires string fields to be valid UTF-8. In Edition 2023, this is controlled by the utf8_validation feature:

• VERIFY (default): reject invalid UTF-8 during parsing
• NONE: accept any byte sequence in string fields

8. Developer Internals

Repository Structure

protocolbuffers/protobuf/
├── src/                          # C++ core library
│   └── google/protobuf/          # 171 source files, 3M chars
│       ├── compiler/             # protoc code generators (C++, Java, Python, C#, etc.)
│       ├── io/                   # CodedInputStream/OutputStream, zero-copy streams
│       ├── json/                 # JSON serialization (C++)
│       ├── stubs/                # Compatibility stubs
│       ├── util/                 # Utility functions
│       ├── any.h/cc              # Any type helpers
│       ├── descriptor.h/cc       # Schema descriptor (reflection)
│       ├── message.h/cc          # Full message interface
│       ├── message_lite.h/cc     # Lite message interface (no reflection)
│       └── wire_format.h/cc      # Wire format encoding/decoding
├── upb/                          # Micro protobuf C library
│   ├── base/                     # Fundamental types
│   ├── mem/                      # Arena memory allocator
│   ├── wire/                     # Binary encode/decode
│   ├── json/                     # JSON encode/decode
│   ├── text/                     # Text format encode/decode
│   ├── mini_table/               # Compact schema tables
│   ├── mini_descriptor/          # Binary schema descriptors
│   ├── reflection/               # Descriptor-based reflection
│   ├── message/                  # Message operations
│   ├── hash/                     # Hash map implementation
│   ├── lex/                      # Lexer utilities
│   ├── port/                     # Platform abstraction
│   ├── util/                     # Utilities
│   └── conformance/              # upb conformance harness
├── upb_generator/                # upb code generator
│   ├── c/                        # C code generator
│   ├── minitable/                # Mini table generator
│   ├── reflection/               # Reflection generator
│   └── common/                   # Shared generator utilities
├── hpb/                          # Header protobuf (C++ API over upb)
│   ├── backend/                  # upb/C++ backend implementations
│   └── internal/                 # Internal utilities
├── hpb_generator/                # hpb code generator
├── java/                         # Java runtime
│   ├── core/                     # protobuf-java
│   ├── lite/                     # protobuf-javalite
│   ├── util/                     # protobuf-java-util (JSON, etc.)
│   ├── kotlin/                   # protobuf-kotlin DSL
│   ├── kotlin-lite/              # protobuf-kotlin-lite DSL
│   ├── bom/                      # Bill of Materials POM
│   ├── osgi/                     # OSGi bundle
│   ├── protoc/                   # protoc Maven artifact POM
│   └── internal/                 # Internal shared code
├── python/                       # Python runtime (C extension + pure Python)
│   ├── google/protobuf/          # Main package
│   │   └── internal/             # Internal implementation (65 files, 1M chars)
│   ├── protobuf_distutils/       # setuptools plugin for protoc integration
│   └── docs/                     # Sphinx documentation config
├── csharp/                       # C# runtime
│   ├── src/                      # Source projects
│   │   ├── Google.Protobuf/      # Main library
│   │   └── Google.Protobuf.Test/ # Tests
│   ├── protos/                   # Test protos
│   └── compatibility_tests/      # v3.0.0 compatibility tests
├── ruby/                         # Ruby runtime
│   ├── ext/                      # C extension (CRuby)
│   ├── lib/                      # Ruby library + FFI (JRuby)
│   └── src/                      # JRuby Java source
├── php/                          # PHP runtime
│   ├── src/                      # PHP classes
│   ├── ext/                      # C extension
│   └── tests/                    # Test suite
├── objectivec/                   # Objective-C runtime (66 files, 1.4M chars)
│   └── DevTools/                 # PDDM macro preprocessor
├── rust/                         # Rust runtime
│   ├── cpp_kernel/               # C++ backend for Rust
│   ├── upb_kernel/               # upb backend for Rust
│   ├── upb/                      # Low-level upb bindings
│   ├── release_crates/           # Published crate sources
│   │   ├── protobuf/             # Main runtime crate
│   │   ├── protobuf_codegen/     # Code generator crate
│   │   ├── protobuf_macros/      # proto! macro crate
│   │   └── protobuf_well_known_types/ # Well-known types
│   └── test/                     # Test infrastructure
├── conformance/                  # Cross-language conformance tests
│   ├── test_protos/              # Test message definitions
│   └── ruby/                     # Ruby conformance harness
├── editions/                     # Editions system
│   ├── golden/                   # Golden test files
│   ├── input/                    # Edition transform inputs
│   └── codegen_tests/            # Code generation tests
├── examples/                     # Tutorial examples (AddressBook)
│   └── go/                       # Go example
├── bazel/                        # Bazel build rules
│   ├── common/                   # Common rules
│   ├── flags/                    # Build flag definitions
│   ├── toolchains/               # Toolchain configs
│   └── private/                  # Internal rules
├── cmake/                        # CMake build support
├── ci/                           # CI configuration
├── benchmarks/                   # Performance benchmarks
├── compatibility/                # Version compatibility tests
├── patches/                      # Patch files for older versions
├── build_defs/                   # Build definition helpers
├── editors/                      # Editor support files
├── pkg/                          # Package configuration
└── toolchain/                    # Toolchain definitions

Core C++ Architecture

The C++ runtime (src/google/protobuf/) is organized around these key abstractions:

Message hierarchy:

MessageLite (minimal interface, no reflection)
  └── Message (full interface with reflection + text format)
       └── Generated classes (e.g., Person, AddressBook)

• MessageLite — base class for all messages; provides SerializeToString(), ParseFromString(), ByteSizeLong(), MergeFrom()
• Message — extends MessageLite with reflection (GetDescriptor(), GetReflection()), text format, and SpaceUsedLong()
• Generated classes — concrete implementations with typed accessors

Descriptor system (reflection):

I/O layer:

upb Architecture Deep Dive

upb is designed for maximum performance with minimal memory overhead:

Arena allocator (upb/mem/):

• All message allocations come from an arena — a bump allocator that frees all memory at once
• Arenas can be fused: two arenas become one, sharing a lifetime
• Arena allocation is ~3x faster than malloc for typical protobuf patterns

Mini tables (upb/mini_table/):

• Compact, cache-friendly representation of message schemas
• Generated at compile time by the upb code generator
• Used by the wire decoder for fast field dispatch
• Internal layout: array of field entries indexed by field number, each entry encodes type, offset, and presence information

Fast decoder (upb/wire/):

• Two-stage decoder: fast path (inline, no function calls for common cases) + slow path (fallback for uncommon wire types)
• decode_fast uses computed-goto dispatch on x86/ARM for ~2 ns per field
• Handles packed repeated fields, submessages, and groups

Reflection (upb/reflection/):

• Full descriptor-based reflection API for dynamic message access
• Used by JSON and text format encoders that need to enumerate fields at runtime
• Significantly more memory than mini tables — only loaded when reflection is needed

Python Runtime Internals

The Python protobuf library (python/) has three backends:

1. upb backend (default): C extension in python/convert.c, python/message.c, python/protobuf.c. Wraps the upb C library for message storage and serialization. Python objects are thin wrappers around upb messages allocated in arenas.

2. Pure Python backend: python/google/protobuf/internal/python_message.py. Full Python implementation using __slots__ and descriptors. ~1450 lines. Supports all features but is 10–50x slower than the upb backend.

3. C++ backend (deprecated): Previously linked against the C++ protobuf library. Being phased out in favor of upb.

Key internal modules:

Note

The Python api_implementation.py module raises ValueError if api_version=1 is requested (removed in v4) and raises ValueError if PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION is set to an unrecognized value.

Rust Runtime Internals

The Rust protobuf implementation (V4) provides a safe API with ownership semantics:

Core types:

Backend architecture:

The Rust runtime supports two backends selected at compile time:

Both backends implement the same traits (Proxied, ViewProxy, MutProxy) behind Private visibility barriers, ensuring the public API is identical regardless of backend.

Extension API:

// Extensions use ExtensionId<Extendee, T> for type-safe access
let ext = ExtensionId::<MyMessage, i32>::new(/* ... */);
ext.set(&mut msg, 42);
let val: i32 = ext.get(&msg);

Objective-C Runtime

The Objective-C runtime (objectivec/, 66 files, 1.4M chars) is one of the largest per-language implementations. It includes:

• PDDM macro preprocessor (objectivec/DevTools/pddm.py): A custom macro expansion system used to generate repetitive Objective-C code for each field type. PDDM definitions in source files are expanded in-place during development.
• Xcode project files for macOS, iOS, and tvOS targets
• Full descriptor and reflection support
• Dynamic message creation

PHP Runtime

PHP minimum version: 8.2.0. The ext-bcmath extension is suggested for proper JSON deserialization of large integers.

Java Runtime

The Java implementation is organized as a Maven multi-module project:

Java target compatibility: Java 8 (source + target 1.8). Build uses maven-antrun-plugin to invoke protoc during test source generation.

Conformance Test Architecture

The conformance testing framework uses a two-process architecture:

┌─────────────────────────┐     stdin/stdout      ┌───────────────────────┐
│ conformance_test_runner │ ◄──── length-prefixed ──► language_harness    │
│ (C++ driver)            │      binary messages   │ (Java/Python/Ruby/   │
│                         │                        │  Rust/C#)            │
│ - Generates test cases  │                        │ - Receives request   │
│ - Validates responses   │                        │ - Parses/serializes  │
│ - Reports pass/fail     │                        │ - Returns response   │
└─────────────────────────┘                        └───────────────────────┘

Communication protocol: 4-byte little-endian length prefix + serialized ConformanceRequest / ConformanceResponse messages.

Test coverage includes:

• Proto2, proto3, edition2023, edition-unstable message types
• Binary ↔ JSON ↔ text format conversions
• Edge cases: default values, unknown fields, oneof clearing, map ordering
• Required field validation (proto2)
• UTF-8 validation
• Group encoding (legacy)

Code Patterns and Conventions

Naming conventions:

Field number allocation:

• 1–15: single-byte tag — use for frequently set fields
• 16–2047: two-byte tag — use for less common fields
• 19000–19999: reserved by protobuf implementation — never use
• 1–536870911 (2^29 - 1): valid range

Generated code naming (by language):

Testing Strategy

Test infrastructure uses protoc to generate test protos during the build process (via Maven Antrun for Java, Bazel genrules for C++/others).

Tip

The Python test suite at python/google/protobuf/internal/ contains 65 files with ~1M chars of tests — one of the most comprehensive test suites in the project. Run with python -m pytest python/google/protobuf/internal/ or via Bazel.

Build System Details

Bazel (primary):

• MODULE.bazel defines external dependencies (abseil-cpp, utf8_range, etc.)
• BUILD.bazel files throughout the tree define targets
• bazel/ contains custom rules: proto_library, java_proto_library, py_proto_library, etc.
• bazel/toolchains/ configures cross-compilation toolchains
• bazel/flags/ defines build configuration flags (C++ standards, Java settings)

CMake (alternative):

• CMakeLists.txt at root
• cmake/dependencies_generator.py converts MODULE.bazel dependencies to CMake variables
• External dependency handling via FetchContent or pre-installed packages
• upb/cmake/ contains CMake-specific build files for the upb library
• Staleness tests (upb/cmake/staleness_test.py) verify generated CMake files match Bazel definitions

Potential Improvements

Based on source analysis:

1. Packed field decoder safety — the OOM issue (#27104) in packed field decoders needs bounds checking before allocation
2. GzipOutputStream validation — buffer_size parameter in GzipOutputStream::Init should validate non-negative values (#27097)
3. Null safety in EpsCopyOutputStream — the array-only constructor should validate internal state before use (#27099)
4. GCC compatibility — build failures with certain GCC versions (#26385) need compiler-specific workarounds
5. CMake + abseil-cpp integration — version mismatch issues (#22209) between protobuf and abseil-cpp builds need smoother dependency resolution

Contributing

The project uses a standard GitHub workflow:

1. Fork the repository
2. Create a feature branch
3. Make changes with tests
4. Run conformance tests: bazel test //conformance/...
5. Run language-specific tests: bazel test //java/..., bazel test //python/..., etc.
6. Submit a pull request

Code style: Follow existing patterns in each language directory. C++ follows Google C++ Style Guide. Java follows Google Java Style Guide. Python follows PEP 8.

License: BSD-3-Clause. All source files include the license header.

CI: Kokoro (Google internal) runs the primary CI. AppVeyor covers Windows builds (Visual Studio 2017, MinGW). CI configurations are in ci/ and appveyor.yml.

9. Integration Points

gRPC Integration

Protobuf is the default serialization format for gRPC. Service definitions in .proto files generate RPC stubs:

service RouteGuide {
  rpc GetFeature(Point) returns (Feature);
  rpc ListFeatures(Rectangle) returns (stream Feature);
  rpc RecordRoute(stream Point) returns (RouteSummary);
  rpc RouteChat(stream RouteNote) returns (stream RouteNote);
}

gRPC plugins are separate from the protobuf compiler but invoked via protoc's plugin system.

Maven Integration (Java)

Use the protobuf-maven-plugin to integrate protoc into Maven builds:

<plugin>
  <groupId>org.xolstice.maven.plugins</groupId>
  <artifactId>protobuf-maven-plugin</artifactId>
  <configuration>
    <protocArtifact>com.google.protobuf:protoc:4.36.0:exe:${os.detected.classifier}</protocArtifact>
  </configuration>
</plugin>

Gradle Integration (Java/Kotlin)

plugins {
    id 'com.google.protobuf' version '0.9.4'
}

protobuf {
    protoc {
        artifact = 'com.google.protobuf:protoc:4.36.0'
    }
}

Python setuptools Integration

The protobuf_distutils package (python/protobuf_distutils/) provides a setuptools command for running protoc during Python package builds:

# setup.py
from setuptools import setup
setup(
    # ...
    options={'generate_py_protobufs': {
        'source_dir': 'protos',
        'output_dir': 'mypackage/protos',
    }},
)

Bazel Integration

load("@protobuf//bazel:proto_library.bzl", "proto_library")
load("@protobuf//bazel:cc_proto_library.bzl", "cc_proto_library")
load("@protobuf//bazel:java_proto_library.bzl", "java_proto_library")
load("@protobuf//bazel:py_proto_library.bzl", "py_proto_library")

proto_library(
    name = "person_proto",
    srcs = ["person.proto"],
    deps = ["@protobuf//:timestamp_proto"],
)

cc_proto_library(name = "person_cc_proto", deps = [":person_proto"])
java_proto_library(name = "person_java_proto", deps = [":person_proto"])
py_proto_library(name = "person_py_proto", deps = [":person_proto"])

NuGet/MSBuild Integration (C#)

The Google.Protobuf.Tools NuGet package bundles protoc and well-known type .proto files for MSBuild integration:

<PackageReference Include="Google.Protobuf" Version="4.36.0" />
<PackageReference Include="Google.Protobuf.Tools" Version="4.36.0" />

Platform binaries included: windows_x86, windows_x64, macosx_x64, linux_x86, linux_x64, linux_aarch64.

Rust Cargo Integration

Use the protobuf_codegen crate in your build.rs:

// build.rs
fn main() {
    protobuf_codegen::CodeGen::new()
        .inputs(&["src/protos/person.proto"])
        .include("src/protos")
        .cargo_out_dir("protobuf_generated")
        .generate()
        .expect("protoc codegen failed");
}

// main.rs
mod protos {
    include!(concat!(env!("OUT_DIR"), "/protobuf_generated/person.rs"));
}

Read the Docs Integration

The Python documentation uses Sphinx with Read the Docs hosting. Configuration:

• .readthedocs.yml at repo root — uses conda environment, Sphinx, Python 3.8
• python/docs/conf.py — Sphinx configuration
• python/docs/requirements.txt — Sphinx dependencies (sphinx 3.0.4, sphinx_rtd_theme 0.4.3)