GitHub user carloea2 edited a discussion: Proposal: Statement-level
Python-to-Texera workflow compiler MVP
## Summary
This proposal adds a first end-to-end path that translates Python source into
an ordinary Texera workflow of Python UDF operators. It reuses the existing
compiler kernel and its working source model, dependency analysis, checking,
realization, and rendering algorithms. The implementation is a smaller modular
composition of that compiler, not a second compiler and not a rewrite from
scratch.
The initial boundary is about **where the compiler may split a program**, not
which normal Python statements a user may write.
## What the compiler does
The user-facing pipeline has four stable stages:
```text
Python source
-> ANALYZE: understand complete statements and their dependencies
-> GROUP: choose which statements should share an operator
-> VERIFY: prove that every value is either local or can cross a boundary
-> BUILD: generate Python UDFs, ports, links, and Texera workflow JSON
```
An **evaluation atom** is simply a set of program operations that cannot be
separated safely. The initial composition closes those atoms under each
complete top-level statement. Therefore the smallest placement unit visible to
the grouping strategy is one complete statement.
## Statement-level does not mean straight-line-only
Control flow, functions, and classes are not rejected merely because of their
syntax. A complete top-level `if`, `for`, `while`, `try`, `with`, function
definition, or class definition is admitted as one opaque placement unit.
Python executes its body normally inside one generated operator.
What is deferred is **decomposing the interior** of those statements across
multiple operators. Future modules may add the dependency and execution
protocols required to split loops, calls, exceptions, or recursion without
changing the grouping interface, checker, renderer, or workflow builder.
Invalid Python still fails during parsing, and a proposed operator boundary
still fails verification when no registered realization can implement it.
## Example
Given:
```python
data = load("a.csv")
for row in data:
clean(row)
model = train(data)
save(model)
```
the initial placement units are:
```text
S1 = data = load("a.csv")
S2 = for row in data: ... # one complete, indivisible unit
S3 = model = train(data)
S4 = save(model)
```
A grouping strategy may propose:
```text
Operator A = {S1, S2}
Operator B = {S3, S4}
```
Verification then proves whether the value required downstream can cross from A
to B. If it can, the selected boundary realization emits explicit export/import
actions. If it cannot, that cut is illegal and a coarser legal grouping must be
selected. The compiler never splits `S2` or invents transport as a repair.
Conceptually, the generated workflow is:
```text
Python UDF A Python UDF B
------------------------------- --------------------------
data = load("a.csv") data = import boundary
for row in data: model = train(data)
clean(row) save(model)
export boundary(data) ----> terminal result
```
## Deterministic grouping strategies
The same analyzed program can be compiled with either strategy:
1. **One statement per operator** proposes the finest statement-level grouping
and serves as a diagnostic/reference strategy.
2. **Square-root contiguous grouping** targets
`K = min(statement_count, ceil(sqrt(physical_LOC)))`
and chooses deterministic contiguous, acyclic groups close to equal
physical-LOC partitions.
Neither strategy may override dependency, transport, or realizability
constraints. One authoritative checker certifies the final proposal.
## Internal architecture
```text
source
-> one parse: source inventory + existing Action/Parameter forest
-> installed analysis modules
-> one authoritative dependence graph
-> evaluation atoms
-> statement placement view
-> grouping strategy
-> expanded placement
-> one checker
-> selected internal and boundary realizations
-> Action projections
-> one UDF composer and one workflow renderer
-> ordinary Texera workflow
```
The forest retains exact Python source and structural information. The
dependence graph records which operations produce and consume semantic values.
The statement placement view is the only solver-facing projection. The checker
owns final legality. Realizations explain how certified local code and
boundaries are materialized. The renderer only composes already-certified
projections.
## Boundary transport and Amber integration
- The `PythonValue` boundary realization determines exactly which required
values cross each operator boundary.
- A shared generic PyTexera runtime performs export/import with Cloudpickle so
aliases, cycles, and supported callables survive a process boundary.
- Generated UDFs import that runtime instead of embedding another runtime or
serializer in every operator.
- The boundary envelope contains only explicitly selected fields; it never
sends the complete Python namespace.
- The result uses Texera's ordinary Python source and tuple operators.
- No Amber scheduler, coordinator, recovery, materialization, worker, or
protocol redesign is required.
MOSAIC owns source semantics, dependency analysis, grouping, and realization
selection. Amber/PyTexera owns generic execution and transport primitives; it
remains unaware of MOSAIC-specific atoms, carriers, colors, or solver rules.
## Extensibility rule
Optional capabilities are installed as modules with explicit dependencies and
contributions. A provider and the projector that interprets its facts are owned
together. Adding support for distributed loops, calls, exceptions, files,
consoles, or resources must add analysis evidence and/or a boundary method
while preserving the same four-stage pipeline.
Feature-specific conditionals must not be scattered through dependence-graph
construction, checking, or rendering, and no module may introduce a second
authoritative graph, checker, or renderer.
## Validation plan
The initial implementation will cover:
- complete-statement atomicity for assignments, expressions, control flow,
functions, and classes;
- statement-unit closure and deterministic grouping;
- positive and negative boundary-realization cases;
- exact required-value and Cloudpickle cross-process transport;
- semantic parity between original Python execution and the generated workflow;
- a real Amber integration test using ordinary Python UDF operators;
- a representative data-science program, with the Wine pipeline expected to
produce roughly 7–10 operators under square-root contiguous grouping.
## Non-goals
This first integration does not distribute the interior of control-flow
statements, functions, classes, recursion, exceptions, or individual
expressions. It also excludes ML-based grouping, whole-namespace transport, and
an Amber engine redesign.
The existing complex-case compiler work remains the reference for later
modules. It is not being discarded or reimplemented.
## Questions for review
1. Is complete top-level statement atomicity the right first placement boundary?
2. Should both deterministic grouping strategies be exposed initially, or
should one-statement-per-operator remain diagnostic only?
3. Is explicit required-value transport through the shared Cloudpickle runtime
sufficient for the first integration?
4. Which end-to-end Python examples should block the first PR?
GitHub link: https://github.com/apache/texera/discussions/8160
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
