How to use accu_book instead of Jupyter

What you are replacing

Jupyter usually runs a kernel over the network (often ZMQ). Cells can run out of order. State hides inside that kernel. Two machines can get different answers.

accu_book is a local document: cells, dependency graph, and jobs live in one reproducible notebook. No network kernel. No hidden kernel process. Same SoftFloat path when you call Accumath through the licensed engine bridge.

This page is the public how-to shape. Exact package names and function calls land when the notebook crate hits 1.0.0.

Two layers (do not mix them up)

1. Open notebook (accu_book) — document, state, DAG, jobs, and thin language wrappers. Free at notebook 1.0.0. This is the Jupyter alternative.
2. Accumath engine — proprietary SoftFloat CAS. Lifetime license. Stays 100% pure Rust. No Python or C bindings inside the engine. You reach it through the licensed engine bridge from the notebook (or a Rust host).

Scenario A — Rust host

Best path for people already in Rust.

1. Add the open accu_book crate when it publishes at 1.0.0.
2. Open or create a notebook document through the Rust API (same local document model the desktop UI uses).
3. Run cells / jobs through that API. Order follows the dependency graph, not “ whichever cell you clicked last.”
4. If you hold an Accumath license and want CAS results, call the engine bridge from the same host. The engine itself stays pure Rust — your wrapper is still talking to Rust, not embedding a foreign CAS.

Scenario B — Python host

For labs that today live in Jupyter + Python.

1. Install the thin Python wrapper that ships with the open notebook (not a rewrite of Accumath in Python).
2. Open the same local notebook document the Rust core uses. Your Python code drives the notebook API; it does not start a Jupyter kernel.
3. Put Python glue in your own scripts for IO, plotting helpers, or lab automation. Keep math that needs Accumath on the licensed engine bridge.
4. Do not expect a pip install accumath engine binding. Accumath stays pure Rust. Python talks to accu_book; Accumath stays behind the bridge when licensed.

Scenario C — C (or anything that can call a C ABI)

For C, C++, Fortran front-ends, or other languages that load a shared library.

1. Use the optional C ABI that sits on the open notebook core (planned with the OSS release).
2. Link your host against that library. Open documents, enqueue jobs, read results through the C functions.
3. Same rule: the ABI wraps accu_book, not the Accumath engine guts. Licensed CAS still goes through the engine bridge from a Rust or notebook path.

Scenario D — Desktop app only

If you just want a notebook on screen:

1. Use the Accumath desktop when it ships (egui shell on top of the same headless core).
2. Or, after OSS 1.0.0, run whatever UI is published for accu_book alone.
3. You do not need Python or C wrappers for this path.

Look and feel: menus, cell editing, and run workflows should stay very similar to Jupyter so people do not relearn habits. Under the hood it is still the local document / dependency graph — not a network kernel with hidden state.

UI familiarity (locked)

The notebook UI is meant to feel like Jupyter where it matters: File / Edit / View / Run-style menus, cell focus, run-this-cell / run-all patterns, and the usual notebook chrome. Workflows should transfer without a training course.

What does not transfer is Jupyter’s architecture: no ZMQ kernel, no out-of-order chaos as the source of truth, no hidden kernel process. Familiar menus on top of a local, reproducible document.

What this how-to will never ask you to do

• Install a network Jupyter kernel for Accumath
• Accept hidden kernel state as “normal”
• Pull Accumath into Python or C as a foreign binding
• Treat the open notebook and the paid engine as the same product

When the concrete commands appear

Package names, cargo add / pip install lines, and C header names will be filled in on this page when accu_book reaches 1.0.0. Until then, this guide locks the scenarios so wrappers are designed for real hosts from day one.

More product context: Open source · Future vision · Early supporter.