Skip to content

bijux-cli-python

Python 3.11+ PyPI License: Apache-2.0 CI Status GitHub Repository

Repository docs bijux-cli-python docs

bijux-cli-python is the Python distribution and native bridge for installing and launching the Bijux command runtime. It also owns the Python DAG helper surface that delegates graph operations to bijux-dag. It remains a packaging and delegation boundary between Python callers and Rust runtimes, not a second source of runtime truth.

Use this page when the issue is about PyPI packaging, launcher behavior, Python-facing parity, interpreter diagnostics, or the bridge rules between Python callers and the Rust runtimes.

Reach For This Package When

  • pip install bijux-cli succeeds but the console script or module entrypoint behaves incorrectly
  • Python and native entrypoints disagree on output, flags, or runtime behavior
  • mounted Python apps fail import, callable resolution, or interpreter checks
  • a Python caller needs DAG helper access without inventing a second DAG protocol

What It Owns

Surface Ownership
packaging Python distribution metadata, entrypoints, and install surface
bridge native bindings, conversion layer, compatibility checks, fallback facade
release parity alignment between bijux binary behavior and Python launcher behavior
DAG helpers Python load/validate/plan/run/inspect/query helpers that preserve bijux-dag JSON payloads
boundary does not redefine runtime semantics already owned by bijux-cli or bijux-dag-cli

What It Must Preserve

  • the same command semantics as the native bijux runtime
  • explicit compatibility checks instead of silent drift between launcher paths
  • DAG helper payloads that stay aligned with the retained bijux-dag JSON contracts
  • structured responses on stdout while mounted-app diagnostics use stderr

Diagnose The Bridge

Check the import, package entrypoint, runtime bridge, and mounted application separately:

python -c 'import bijux_cli_py; print(bijux_cli_py.__file__)'
python -m bijux_cli_py version
bijux doctor python
bijux apps doctor <python-mounted-app>

An import failure belongs to packaging, wheel compatibility, or interpreter selection. A successful import followed by an app-doctor failure points instead to mount metadata, callable resolution, or the mounted-app protocol. Keeping those cases separate avoids treating every Python failure as a native bridge defect.

Mounted apps must reserve stdout for their structured response and send diagnostics to stderr. They must not depend on repository source paths or a development virtual environment. When release packaging is in scope, build the wheel and validate it from an isolated installation rather than importing from the checkout.

Compatibility Boundary

The Python distribution follows the workspace release line, while wheel tags and supported interpreters remain package-specific concerns. A conversion change requires Rust and Python parity tests. A public mounted-app protocol change requires the owning CLI contract, package documentation, and app SDK tests to change together.

Source Layout

  • crates/bijux-cli-python/pyproject.toml
  • crates/bijux-cli-python/python/bijux_cli_py
  • crates/bijux-cli-python/python/bijux_cli_py/dag_sdk.py
  • crates/bijux-cli-python/src/lib.rs
  • crates/bijux-cli-python/src/bindings.rs
  • crates/bijux-cli-python/src/conversions.rs
  • crates/bijux-cli-python/src/compatibility.rs
  • crates/bijux-cli-python/tests

Practical Starting Points

  • open the CLI Handbook for product-level runtime behavior
  • open bijux-cli when the question is native runtime ownership rather than distribution or bridge mechanics
  • open bijux-dag when the question is DAG runtime semantics rather than Python delegation
  • open the Repository Handbook when the issue touches release governance, workspace policy, or cross-program ownership

Code Anchors

  • crates/bijux-cli-python/README.md
  • crates/bijux-cli-python/Cargo.toml
  • crates/bijux-cli-python/pyproject.toml
  • crates/bijux-cli-python/tests/python/test_runtime_parity.py
  • crates/bijux-cli-python/tests/runtime_entrypoint_unity.rs
  • crates/bijux-cli-python/tests/python/test_dag_sdk_transport.py
  • crates/bijux-cli-python/tests/python/test_dag_sdk_workflows.py

Review Focus

  • Python-facing entrypoints should preserve runtime parity instead of drifting into custom behavior
  • DAG helpers should return the same structured payloads a caller would receive from bijux-dag --json
  • package metadata should route readers back to the CLI handbook rather than duplicating it
  • release changes should keep bridge compatibility explicit and test-backed