Files
app/backend
stroblmeandClaude Fable 5 11e60cb6a8 Make both distributions fit to publish
The release workflow was already right; what it would have uploaded was not.
`fluksio` had no readme, so its PyPI page would have been blank — the app
repo's own README is a contributor's map of `frontend/` and `docker/`, which
is the wrong front page for `pip install fluksio`. It now has one of its own,
aimed at somebody who landed on the project page. Both distributions gain
authors, urls, keywords and classifiers; `twine check` passes clean on all
four artifacts where it warned on two before.

The workflow publishes `fluksio-worker` first, because `fluksio` depends on it
and the other order leaves a few seconds — the whole of a first release — in
which the dependency cannot be resolved. `--check-url` makes a re-run skip
what is already uploaded rather than failing on it, which matters because a
version on PyPI can never be replaced.

Licence metadata is deliberately still absent: LICENSE is MIT in somebody
else's name, inherited from the template this was scaffolded from, and whose
it should be is not a decision to make in a commit. NOTEPAD carries it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012ue1tkFWB1bcGy3aWhCKpU
2026-08-24 11:21:33 +02:00
..

Fluksio

A node-based automation engine: flows, dashboards and batch runs, in one resident process with no infrastructure behind it.

pip install fluksio
fluksio serve

That is the whole installation — no Docker, no database server, no ports to open. It keeps a SQLite database, a git repository of your flows and an artifact store under ~/.fluksio, and prints an admin password once.

For data science

Your functions become nodes where they already live. Install Fluksio into the environment you work in and your nodes run on it — the packages are already there:

# myresearch/train.py
import fluksio
from fluksio import Port, node

@node(
    requires=["dataset", Port("lr", "float")],
    provides=[Port("loss", "float", stream=True), Port("weights", "artifact")],
    device="gpu", device_policy="prefer",
)
def fit(dataset, lr, epochs=25):
    for epoch in range(epochs):
        loss = step(...)
        yield {"loss": loss}          # published as it happens, kept as a series
    return {"weights": fluksio.save_artifact("weights.pt")}
# myresearch/pipeline.py
from fluksio import Flow, Port
from myresearch.train import fit

train = Flow("train", nodes=[prepare, fit, evaluate],
             inputs=[Port("lr", "float", initial=0.01)], outputs=["score"])
fluksio login --url http://127.0.0.1:8000
fluksio sync myresearch
fluksio run train --lr 0.05 --wait

The decorators return your functions untouched, so everything stays callable, testable and importable as what it was. A metric leaves through a declared port rather than a logging call, which is why there is no log_metric(): the run keeps the whole series, a chart can bind to it, and a downstream node can consume it.

What else it does

  • Flows — typed messages between nodes, wired by name, edited on a canvas or declared in code. Every change is a commit in a git repository you own.
  • Runs — an experiment and a CI-style job are the same entity. Parameters, seed, result, per-node timings, artifacts and the commit it ran at.
  • Dashboards — charts and controls bound to the same messages the flows carry, with no separate metrics pipeline.
  • Remote workerspip install fluksio-worker on the GPU box; it dials out over one websocket, so nothing there has to be reachable.

Python 3.10 or newer, Linux or macOS.