Skip to content

offscale/cdd-python-all

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

62 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

cdd-python-all

License interactive WASM web demo CI Test Coverage Doc Coverage

Compiler Driven Development (CDD) is a development approach designed to eradicate the disconnect between: API specifications; server implementations; client SDKs; and command-line tooling.

Unlike traditional code generators—that treat outputs as disposable or read-only—CDD provides a complete, standalone compiler for each supported language. These compilers are fully CST-aware (Concreate Syntax Tree is a whitespace+comment aware Abstract Syntax Tree), allowing true bidirectional synchronization between existing hand-edited source code and OpenAPI specifications.


🏗️ The Standalone Compiler Architecture

Traditional tools use naïve templating—if you regenerate, your custom code is overwritten.

The CDD ecosystem is fundamentally different. It utilizes language-specific, standalone compilers capable of full AST parsing, semantic diffing, and surgical patching.

The Core Guarantee: Every part of the generated codebase is fully editable. You are encouraged to open the generated routing files, model definitions, and CLI structures, and directly inject your business logic.

  • When your specification changes, the CDD compiler reads your code, builds an AST, diffs it against the new spec, and safely patches in new endpoints or fields without touching your custom logic.
  • When your codebase changes, the compiler reverse-engineers your structural updates back into a 100% accurate, authoritative OpenAPI specification.

🔄 The Bidirectional Synchronization Loop

flowchart TD
    OAS["📄 OpenAPI v3 Spec"] <--> CDD{"⚙️ CDD Compiler"}

    CDD <--> Codebase

    subgraph Codebase ["💻 Application Codebase"]
        direction TB

        subgraph Outputs ["📦 Primary Outputs"]
            direction TB
            CLI["⌨️ CLI Tooling"]
            SDK["📦 Client SDK"]
            Server["🖥️ Server"]

            %% Force vertical stacking inside the subgraph
            CLI ~~~ SDK ~~~ Server
        end

        subgraph Core ["🔗 Core Architecture"]
            direction TB
            Models["🔗 Data Models"]
            Routes["🔀 API Routes"]
            Tests["🧪 Tests"]

            %% Force vertical stacking inside the subgraph
            Models ~~~ Routes ~~~ Tests
        end

        Mocks["🎭 API Mocks / Fakes"]

        %% Simple dependency flow down the page
        Outputs --> Core
        Tests --> Mocks
    end

    style OAS fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style CDD fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
    style Codebase fill:#fafafa,stroke:#9e9e9e,stroke-width:2px,stroke-dasharray: 5 5
    style Outputs fill:#e8f5e9,stroke:#43a047,stroke-width:2px
    style Core fill:#fff3e0,stroke:#f57c00,stroke-width:2px
Loading

The CDD lifecycle supports continuous evolution from any starting point:

  1. Generate: Scaffold servers, SDKs, or CLIs from a central specification.
  2. Edit: Developers write real, unconstrained code directly in the generated files.
  3. Extract: Reverse-compile the edited code to produce an updated OpenAPI spec.
  4. Sync: Apply new specification changes seamlessly into the existing, hand-edited codebase.

🌐 The Global Language Ecosystem

Every supported language operates on the same core CDD philosophies but is powered by a dedicated, native compiler tailored to that language's specific AST, idioms, and package management.

All implementations share a standardized CLI interface (cdd [subcommand]), acting as a universal toolchain.

Repository Language Client; Client CLI; Server Extra features Standards CI Status
cdd-c C (C89) Client; Client CLI; Server FFI Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-cpp C++ Client; Client CLI; Server Upgrades Swagger & Google Discovery to OpenAPI 3.2.0 Google Discovery; Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-csharp C# Client; Client CLI; Server CLR Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-go Go Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-java Java Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-kotlin Kotlin (ktor for Multiplatform) Client; Client CLI; Server Auto-Admin UI Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-php PHP Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-python Python N/A (server building blocks) CLI ↔ SQL ↔ Pydantic ↔ docs ↔ JSON-schema N/A Linting, testing, coverage, and release
cdd-python-all Python Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-ruby Ruby Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-rust Rust Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-sh Shell (/bin/sh) Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-swift Swift Client; Client CLI; Server Swagger 2.0 & OpenAPI 3.2.0 CI
cdd-ts TypeScript Client; Client CLI; Server Auto-Admin UI; Angular; React; Vue; fetch; Axios; Node.js Swagger 2.0 & OpenAPI 3.2.0 Tests and coverage

🛠️ Universal CLI Toolchain

A true ecosystem requires standardized tooling. Once a developer learns the CDD toolchain, they can synchronize architecture across the entire polyglot stack.

Global Arguments

  • --help: Print help information.
  • --version: Print version information.
  • --input, -i (or -f): Target file, directory, or OpenAPI spec.
  • --output, -o: Destination path for generation or sync.

Core Subcommands

from_openapi to_sdk_cli

Generate a client SDK and a corresponding command-line interface (CLI) from an OpenAPI specification.

  • --input, -i <spec>: Path to the OpenAPI specification file.

from_openapi to_sdk

Generate a client SDK from an OpenAPI specification.

  • --input, -i <spec>: Path to the OpenAPI specification file.

from_openapi to_server

Generate server boilerplate, models, and routing logic from an OpenAPI specification.

  • --input, -i <spec>: Path to the OpenAPI specification file.

to_openapi

Parse the existing codebase and extract an authoritative OpenAPI specification.

  • --input, -i <path> (or -f <path>): Path to the source code directory or file to parse.

to_docs_json

Convert an OpenAPI specification into a localized, documentation-optimized JSON format.

  • --input, -i <spec>: Path to the OpenAPI specification file.
  • --no-imports: Disable import statements in the generated documentation.
  • --no-wrapping: Disable line wrapping in the generated documentation.

serve_json_rpc

Launch a JSON-RPC server for editor and tool integrations.

  • --port <port> (or -p): Port to listen on (e.g., 8080).
  • --listen <address> (or -l): Address to bind to (e.g., 0.0.0.0).

mcp

Run the Model Context Protocol server via stdio.

sync

Sync a directory containing client.py, mock_server.py, test_client.py, cli_main.py

  • --dir <dir>: Path to directory containing Python files to sync.
  • --truth {class,sqlalchemy,function,openapi}: Designate a single source of truth for synchronization.

Detail Features Beyond Common Subset

  • Model Context Protocol (MCP): Native support to generate an MCP server and adapter (--mcp), and run the MCP server over stdio.
  • Directory Synchronization: Uniquely features a sync command to harmonize client.py, mock_server.py, test_client.py, and cli_main.py with configurable sources of truth (class, sqlalchemy, function, openapi).
  • Comprehensive Scaffolding: Optionally generates GitHub Actions pipelines and installable Python package scaffolding automatically.
  • Integration Testing & Mocks: Emits full integration tests and mock servers during generation (--tests).
  • Batch Processing: Capable of reading from an entire directory of OpenAPI specifications (--input-dir) simultaneously.

🚀 The End of "Spec Drift"

With Compiler Driven Development, specifications and code are no longer loosely coupled artifacts. They are strict, isomorphic reflections of one another, maintained by dedicated standalone compilers.

Choose your language ecosystem above and start treating your architecture as a seamlessly compiled, endlessly editable whole.


License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

About

OpenAPI ↔ Python

Resources

License

Apache-2.0, MIT licenses found

Licenses found

Apache-2.0
LICENSE-APACHE
MIT
LICENSE-MIT

Stars

Watchers

Forks

Packages

 
 
 

Contributors

Languages