rappel 0.5.1__py3-none-manylinux_2_39_aarch64.whl

rappel/workflow_runtime.py

@@ -0,0 +1,287 @@
+"""Runtime helpers for executing actions inside the worker.
+
+This module provides the execution layer for Python workers that receive
+action dispatch commands from the Rust scheduler.
+"""
+
+import asyncio
+import dataclasses
+from base64 import b64decode
+from dataclasses import dataclass
+from datetime import date, datetime, time, timedelta
+from decimal import Decimal
+from pathlib import Path, PurePath
+from typing import Any, Dict, get_args, get_origin, get_type_hints
+from uuid import UUID
+
+from pydantic import BaseModel
+
+from proto import messages_pb2 as pb2
+
+from .dependencies import provide_dependencies
+from .registry import registry
+from .serialization import arguments_to_kwargs
+
+
+class WorkflowNodeResult(BaseModel):
+    """Result from a workflow node execution containing variable bindings."""
+
+    variables: Dict[str, Any]
+
+
+@dataclass
+class ActionExecutionResult:
+    """Result of an action execution."""
+
+    result: Any
+    exception: BaseException | None = None
+
+
+def _is_pydantic_model(cls: type) -> bool:
+    """Check if a class is a Pydantic BaseModel subclass."""
+    try:
+        return isinstance(cls, type) and issubclass(cls, BaseModel)
+    except TypeError:
+        return False
+
+
+def _is_dataclass_type(cls: type) -> bool:
+    """Check if a class is a dataclass."""
+    return dataclasses.is_dataclass(cls) and isinstance(cls, type)
+
+
+def _coerce_primitive(value: Any, target_type: type) -> Any:
+    """Coerce a value to a primitive type based on target_type.
+
+    Handles conversion of serialized values (strings, floats) back to their
+    native Python types (UUID, datetime, etc.).
+    """
+    # Handle None
+    if value is None:
+        return None
+
+    # UUID from string
+    if target_type is UUID:
+        if isinstance(value, UUID):
+            return value
+        if isinstance(value, str):
+            return UUID(value)
+        return value
+
+    # datetime from ISO string
+    if target_type is datetime:
+        if isinstance(value, datetime):
+            return value
+        if isinstance(value, str):
+            return datetime.fromisoformat(value)
+        return value
+
+    # date from ISO string
+    if target_type is date:
+        if isinstance(value, date):
+            return value
+        if isinstance(value, str):
+            return date.fromisoformat(value)
+        return value
+
+    # time from ISO string
+    if target_type is time:
+        if isinstance(value, time):
+            return value
+        if isinstance(value, str):
+            return time.fromisoformat(value)
+        return value
+
+    # timedelta from total seconds
+    if target_type is timedelta:
+        if isinstance(value, timedelta):
+            return value
+        if isinstance(value, (int, float)):
+            return timedelta(seconds=value)
+        return value
+
+    # Decimal from string
+    if target_type is Decimal:
+        if isinstance(value, Decimal):
+            return value
+        if isinstance(value, (str, int, float)):
+            return Decimal(str(value))
+        return value
+
+    # bytes from base64 string
+    if target_type is bytes:
+        if isinstance(value, bytes):
+            return value
+        if isinstance(value, str):
+            return b64decode(value)
+        return value
+
+    # Path from string
+    if target_type is Path or target_type is PurePath:
+        if isinstance(value, PurePath):
+            return value
+        if isinstance(value, str):
+            return Path(value)
+        return value
+
+    return value
+
+
+# Types that can be coerced from serialized form
+COERCIBLE_TYPES = (UUID, datetime, date, time, timedelta, Decimal, bytes, Path, PurePath)
+
+
+def _coerce_dict_to_model(value: Any, target_type: type) -> Any:
+    """Convert a dict to a Pydantic model or dataclass if needed.
+
+    If value is a dict and target_type is a Pydantic model or dataclass,
+    instantiate the model with the dict values. Otherwise, return value unchanged.
+    """
+    if not isinstance(value, dict):
+        return value
+
+    if _is_pydantic_model(target_type):
+        # Use model_validate for Pydantic v2, fall back to direct instantiation
+        model_validate = getattr(target_type, "model_validate", None)
+        if model_validate is not None:
+            return model_validate(value)
+        return target_type(**value)
+
+    if _is_dataclass_type(target_type):
+        return target_type(**value)
+
+    return value
+
+
+def _coerce_value(value: Any, target_type: type) -> Any:
+    """Coerce a value to the target type.
+
+    Handles:
+    - Primitive types (UUID, datetime, etc.)
+    - Pydantic models and dataclasses (from dicts)
+    - Generic collections like list[UUID], set[datetime]
+    """
+    # Handle None
+    if value is None:
+        return None
+
+    # Check for coercible primitive types
+    if isinstance(target_type, type) and issubclass(target_type, COERCIBLE_TYPES):
+        return _coerce_primitive(value, target_type)
+
+    # Check for Pydantic models or dataclasses
+    if isinstance(value, dict):
+        coerced = _coerce_dict_to_model(value, target_type)
+        if coerced is not value:
+            return coerced
+
+    # Handle generic types like list[UUID], set[datetime]
+    origin = get_origin(target_type)
+    if origin is not None:
+        args = get_args(target_type)
+
+        # Handle list[T]
+        if origin is list and isinstance(value, list) and args:
+            item_type = args[0]
+            return [_coerce_value(item, item_type) for item in value]
+
+        # Handle set[T] (serialized as list)
+        if origin is set and isinstance(value, list) and args:
+            item_type = args[0]
+            return {_coerce_value(item, item_type) for item in value}
+
+        # Handle frozenset[T] (serialized as list)
+        if origin is frozenset and isinstance(value, list) and args:
+            item_type = args[0]
+            return frozenset(_coerce_value(item, item_type) for item in value)
+
+        # Handle tuple[T, ...] (serialized as list)
+        if origin is tuple and isinstance(value, (list, tuple)) and args:
+            # Variable length tuple like tuple[int, ...]
+            if len(args) == 2 and args[1] is ...:
+                item_type = args[0]
+                return tuple(_coerce_value(item, item_type) for item in value)
+            # Fixed length tuple like tuple[int, str, UUID]
+            return tuple(
+                _coerce_value(item, item_type) for item, item_type in zip(value, args, strict=False)
+            )
+
+        # Handle dict[K, V]
+        if origin is dict and isinstance(value, dict) and len(args) == 2:
+            key_type, val_type = args
+            return {
+                _coerce_value(k, key_type): _coerce_value(v, val_type) for k, v in value.items()
+            }
+
+    return value
+
+
+def _coerce_kwargs_to_type_hints(handler: Any, kwargs: Dict[str, Any]) -> Dict[str, Any]:
+    """Coerce kwargs to expected types based on handler's type hints.
+
+    Handles:
+    - Pydantic models and dataclasses (from dicts)
+    - Primitive types like UUID, datetime, Decimal, etc.
+    - Generic collections like list[UUID], dict[str, datetime]
+    """
+    try:
+        type_hints = get_type_hints(handler)
+    except Exception:
+        # If we can't get type hints (e.g., forward references), return as-is
+        return kwargs
+
+    coerced = {}
+    for key, value in kwargs.items():
+        if key in type_hints:
+            target_type = type_hints[key]
+            coerced[key] = _coerce_value(value, target_type)
+        else:
+            coerced[key] = value
+
+    return coerced
+
+
+async def execute_action(dispatch: pb2.ActionDispatch) -> ActionExecutionResult:
+    """Execute an action based on the dispatch command.
+
+    Args:
+        dispatch: The action dispatch command from the Rust scheduler.
+
+    Returns:
+        The result of executing the action.
+    """
+    action_name = dispatch.action_name
+    module_name = dispatch.module_name
+
+    # Import the module if specified (this registers actions via @action decorator)
+    if module_name:
+        import importlib
+
+        importlib.import_module(module_name)
+
+    # Get the action handler using both module and name
+    handler = registry.get(module_name, action_name)
+    if handler is None:
+        return ActionExecutionResult(
+            result=None,
+            exception=KeyError(f"action '{module_name}:{action_name}' not registered"),
+        )
+
+    # Deserialize kwargs
+    kwargs = arguments_to_kwargs(dispatch.kwargs)
+
+    # Coerce dict arguments to Pydantic models or dataclasses based on type hints
+    # This is needed because the IR converts model constructor calls to dicts
+    kwargs = _coerce_kwargs_to_type_hints(handler, kwargs)
+
+    try:
+        async with provide_dependencies(handler, kwargs) as call_kwargs:
+            value = handler(**call_kwargs)
+            if asyncio.iscoroutine(value):
+                value = await value
+        return ActionExecutionResult(result=value)
+    except Exception as e:
+        return ActionExecutionResult(
+            result=None,
+            exception=e,
+        )

rappel-0.5.1.dist-info/METADATA

@@ -0,0 +1,299 @@
+Metadata-Version: 2.4
+Name: rappel
+Version: 0.5.1
+Summary: Distributed & durable background events in Python
+Requires-Python: >=3.10
+Requires-Dist: googleapis-common-protos>=1.72.0
+Requires-Dist: grpcio<2,>=1.66
+Requires-Dist: protobuf<6,>=5.29
+Requires-Dist: pydantic<3,>=2
+Provides-Extra: dev
+Requires-Dist: pytest>=8; extra == 'dev'
+Description-Content-Type: text/markdown
+
+# rappel
+
+![Rappel Logo](https://raw.githubusercontent.com/piercefreeman/rappel/main/media/header.png)
+
+rappel is a library to let you build durable background tasks that withstand server restarts, task crashes, and long-running jobs. It's built for Python and Postgres without any additional deploy time requirements.
+
+## Usage
+
+Let's say you need to send welcome emails to a batch of users, but only the active ones. You want to fetch them all, filter out inactive accounts, then fan out emails in parallel. This is how you write that workflow in rappel:
+
+```python
+import asyncio
+from rappel import Workflow, action, workflow
+
+@workflow
+class WelcomeEmailWorkflow(Workflow):
+    async def run(self, user_ids: list[str]) -> list[EmailResult]:
+        users = await fetch_users(user_ids)
+        active_users = [user for user in users if user.active]
+
+        results = await asyncio.gather(*[
+            send_email(to=user.email, subject="Welcome")
+            for user in active_users
+        ])
+        
+        return results
+```
+
+And here's how you define the actions distributed to your worker cluster:
+
+```python
+@action
+async def fetch_users(
+    user_ids: list[str],
+    db: Annotated[Database, Depend(get_db)],
+) -> list[User]:
+    return await db.get_many(User, user_ids)
+
+@action
+async def send_email(
+    to: str,
+    subject: str,
+    emailer: Annotated[EmailClient, Depend(get_email_client)],
+) -> EmailResult:
+    return await emailer.send(to=to, subject=subject)
+```
+
+To kick off a background job and wait for completion:
+
+```python
+async def welcome_users(user_ids: list[str]):
+    workflow = WelcomeEmailWorkflow()
+    await workflow.run(user_ids)
+```
+
+When you call `await workflow.run()`, we parse the AST of your `run()` method and compile it into the Rappel Runtime Language. The `for` loop becomes a filter node, the `asyncio.gather` becomes a parallel fan-out. None of this executes inline in your webserver, instead it's queued to Postgres and orchestrated by the Rust runtime across your worker cluster.
+
+**Actions** are the distributed work: network calls, database queries, anything that can fail and should be retried independently.
+
+**Workflows** are the control flow: loops, conditionals, parallel branches. They orchestrate actions but don't do heavy lifting themselves.
+
+### Complex Workflows
+
+Workflows can get much more complex than the example above:
+
+1. Customizable retry policy
+
+    By default your Python code will execute like native logic would: any exceptions will throw and immediately fail. Actions are set to timeout after ~5min to keep the queues from backing up - although we will continuously retry timed out actions in case they were caused by a failed node in your cluster. If you want to control this logic to be more robust, you can set retry policies and backoff intervals so you can attempt the action multiple times until it succeeds.
+
+    ```python
+    from rappel import RetryPolicy, BackoffPolicy
+    from datetime import timedelta
+
+    async def run(self):
+        await self.run_action(
+            inconsistent_action(0.5),
+            # control handling of failures
+            retry=RetryPolicy(attempts=50),
+            backoff=BackoffPolicy(base_delay=5),
+            timeout=timedelta(minutes=10)
+        )
+    ```
+
+1. Branching control flows
+
+    Use if statements, for loops, or any other Python primitives within the control logic. We will automatically detect these branches and compile them into a DAG node that gets executed just like your other actions.
+
+    ```python
+    async def run(self, user_id: str) -> Summary:
+        # loop + non-action helper call
+        top_spenders: list[float] = []
+        for record in summary.transactions.records:
+            if record.is_high_value:
+                top_spenders.append(record.amount)
+    ```
+
+1. asyncio primitives
+
+    Use asyncio.gather to parallelize tasks. Use asyncio.sleep to sleep for a longer period of time.
+
+    ```python
+    import asyncio
+
+    async def run(self, user_id: str) -> Summary:
+        # parallelize independent actions with gather
+        profile, settings, history = await asyncio.gather(
+            fetch_profile(user_id=user_id),
+            fetch_settings(user_id=user_id),
+            fetch_purchase_history(user_id=user_id)
+        ) 
+
+        # wait before sending email
+        await asyncio.sleep(24*60*60)
+        recommendations = await email_ping(history)
+
+        return Summary(profile=profile, settings=settings, recommendations=recommendations)
+    ```
+
+### Error handling
+
+To build truly robust background tasks, you need to consider how things can go wrong. Actions can 'fail' in a couple ways. This is supported by our `.run_action` syntax that allows users to provide additional parameters to modify the execution bounds on each action.
+
+1. Action explicitly throws an error and we want to retry it. Caused by intermittent database connectivity / overloaded webservers / or simply buggy code will throw an error. This comes from a standard python `raise Exception()`
+1. Actions raise an error that is a really a RappelTimeout. This indicates that we dequeued the task but weren't able to complete it in the time allocated. This could be because we dequeued the task, started work on it, then the server crashed. Or it could still be running in the background but simply took too much time. Either way we will raise a synthetic error that is representative of this execution.
+
+By default we will only try explicit actions one time if there is an explicit exception raised. We will try them infinite times in the case of a timeout since this is usually caused by cross device coordination issues.
+
+## Project Status
+
+_NOTE: Right now you shouldn't use rappel in any production applications. The spec is changing too quickly and we don't guarantee backwards compatibility before 1.0.0. But we would love if you try it out in your side project and see how you find it._
+
+Rappel is in an early alpha. Particular areas of focus include:
+
+1. Finalizing the Rappel Runtime Language
+1. Extending AST parsing logic to handle most core control flows
+1. Performance tuning
+1. Unit and integration tests
+
+If you have a particular workflow that you think should be working but isn't yet producing the correct DAG (you can visualize it via CLI by `.visualize()`) please file an issue.
+
+## Configuration
+
+The main rappel configuration is done through env vars, which is what you'll typically use in production when using a docker deployment pipeline. If we can't find an environment parameter we will fallback to looking for an .env that specifies it within your local filesystem.
+
+These are the primary environment parameters that you'll likely want to customize for your deployment:
+
+| Environment Variable | Description | Default | Example |
+|---------------------|-------------|---------|---------|
+| `RAPPEL_DATABASE_URL` | PostgreSQL connection string for the rappel server | (required on bridge &workers ) | `postgresql://user:pass@localhost:5433/rappel` |
+| `RAPPEL_WORKER_COUNT` | Number of Python worker processes | `num_cpus` | `8` |
+| `RAPPEL_CONCURRENT_PER_WORKER` | Max concurrent actions per worker | `10` | `20` |
+| `RAPPEL_USER_MODULE` | Python module preloaded into each worker | none | `my_app.actions` |
+| `RAPPEL_POLL_INTERVAL_MS` | Poll interval for the dispatch loop (ms) | `100` | `50` |
+| `RAPPEL_WEBAPP_ENABLED` | Enable the web dashboard | `false` | `true` |
+| `RAPPEL_WEBAPP_ADDR` | Web dashboard bind address | `0.0.0.0:24119` | `0.0.0.0:8080` |
+
+We expect that you won't need to modify the following env parameters, but we provide them for convenience:
+
+| Environment Variable | Description | Default | Example |
+|---------------------|-------------|---------|---------|
+| `RAPPEL_HTTP_ADDR` | HTTP bind address for `rappel-bridge` | `127.0.0.1:24117` | `0.0.0.0:24117` |
+| `RAPPEL_GRPC_ADDR` | gRPC bind address for `rappel-bridge` | HTTP port + 1 | `0.0.0.0:24118` |
+| `RAPPEL_BATCH_SIZE` | Max actions fetched per poll | `workers * concurrent_per_worker` | `200` |
+
+## Philosophy
+
+Background jobs in webapps are so frequently used that they should really be a primitive of your fullstack library: database, backend, frontend, _and_ background jobs. Otherwise you're stuck in a situation where users either have to always make blocking requests to an API or you spin up ephemeral tasks that will be killed during re-deployments or an accidental docker crash.
+
+After trying most of the ecosystem in the last 3 years, I believe background jobs should provide a few key features:
+
+- Easy to write control flow in normal Python
+- Should be both very simple to test locally and very simple to deploy remotely
+- Reasonable default configurations to scale to a reasonable request volume without performance tuning
+
+On the point of control flow, we shouldn't be forced into a DAG definition (decorators, custom syntax). It should be regular control flow just distinguished because the flows are durable and because some portions of the parallelism can be run across machines.
+
+Nothing on the market provides this balance - `rappel` aims to try. We don't expect ourselves to reach best in class functionality for load performance. Instead we intend for this to scale _most_ applications well past product market fit.
+
+## How It Works
+
+Rappel takes a different approach from replay-based workflow engines like Temporal or Vercel Workflow.
+
+| Approach | How it works | Constraint on users |
+|----------|-------------|-------------------|
+| **Temporal/Vercel Workflows** | Replay-based. Your workflow code re-executes from the beginning on each step; completed activities return cached results. | Code must be deterministic. No `random()`, no `datetime.now()`, no side effects in workflow logic. |
+| **Rappel** | Compile-once. Parse your Python AST → intermediate representation → DAG. Execute the DAG directly. Your code never re-runs. | Code must use supported patterns. But once parsed, a node is self-aware where it lives in the computation graph. |
+
+When you decorate a class with `@workflow`, Rappel parses the `run()` method's AST and compiles it to an intermediate representation (IR). This IR captures your control flow—loops, conditionals, parallel branches—as a static directed graph. The DAG is stored in Postgres and executed by the Rust runtime. Your original Python run definition is never re-executed during workflow recovery.
+
+This is convenient in practice because it means that if your workflow compiles, your workflow will run as advertised. There's no need to hack around stdlib functions that are non-deterministic (like time/uuid/etc) because you'll get an error on compilation to switch these into an explicit `@action` where all non-determinism should live.
+
+## Other options
+
+**When should you use Rappel?**
+
+- You're already using Python & Postgres for the core of your stack, either with Mountaineer or FastAPI
+- You have a lot of async heavy logic that needs to be durable and can be retried if it fails (common with 3rd party API calls, db jobs, etc)
+- You want something that works the same locally as when deployed remotely
+- You want background job code to plug and play with your existing unit test & static analysis stack
+- You are focused on getting to product market fit versus scale
+
+Performance is a top priority of rappel. That's why it's written with a Rust core, is lightweight on your database connection by isolating them to ~1 pool per machine host, and runs continuous benchmarks on CI. But it's not the _only_ priority. After all there's only so much we can do with Postgres as an ACID backing store. Once you start to tax Postgres' capabilities you're probably at the scale where you should switch to a more complicated architecture.
+
+**When shouldn't you?**
+
+- You have particularly latency sensitive background jobs, where you need <100ms acknowledgement and handling of each task.
+- You have a huge scale of concurrent background jobs, order of magnitude >10k actions being coordinated concurrently.
+- You have tried some existing task coordinators and need to scale your solution to the next 10x worth of traffic.
+
+There is no shortage of robust background queues in Python, including ones like Temporal.io/RabbitMQ that scale to millions of requests a second.
+
+Almost all of these require a dedicated task broker that you host alongside your app. This usually isn't a huge deal during POCs but can get complex as you need to performance tune it for production. Cloud hosting of most of these are billed per-event and can get very expensive depending on how you orchestrate your jobs. They also typically force you to migrate your logic to fit the conventions of the framework.
+
+Open source solutions like RabbitMQ have been battle tested over decades & large companies like Temporal are able to throw a lot of resources towards optimization. Both of these solutions are great choices - just intended to solve for different scopes. Expect an associated higher amount of setup and management complexity.
+
+## Worker Pool
+
+`start-workers` is the main invocation point to boot your worker cluster on a new node. It launches the gRPC bridge plus a polling dispatcher that streams
+queued actions from Postgres into the Python workers. You should use this as your docker entrypoint:
+
+```bash
+$ cargo run --bin start-workers
+```
+
+## Development
+
+### Packaging
+
+Use the helper script to produce distributable wheels that bundle the Rust executables with the
+Python package:
+
+```bash
+$ uv run scripts/build_wheel.py --out-dir target/wheels
+```
+
+The script compiles every Rust binary (release profile), stages the required entrypoints
+(`rappel-bridge`, `boot-rappel-singleton`) inside the Python package, and invokes
+`uv build --wheel` to produce an artifact suitable for publishing to PyPI.
+
+### Local Server Runtime
+
+The Rust runtime exposes both HTTP and gRPC APIs via the `rappel-bridge` binary:
+
+```bash
+$ cargo run --bin rappel-bridge
+```
+
+Developers can either launch it directly or rely on the `boot-rappel-singleton` helper which finds (or starts) a single shared instance on
+`127.0.0.1:24117`. The helper prints the active HTTP port to stdout so Python clients can connect without additional
+configuration:
+
+```bash
+$ cargo run --bin boot-rappel-singleton
+24117
+```
+
+The Python bridge automatically shells out to the helper unless you provide `RAPPEL_SERVER_URL`
+(`RAPPEL_GRPC_ADDR` for direct sockets) overrides. Once the ports are known it opens a gRPC channel to the
+`WorkflowService`.
+
+### Benchmarking
+
+Stream benchmark output directly into our parser to summarize throughput and latency samples:
+
+```bash
+$ cargo run --bin bench -- \
+  --messages 100000 \
+  --payload 1024 \
+  --concurrency 64 \
+  --workers 4 \
+  --log-interval 15 \
+  uv run python/tools/parse_bench_logs.py
+
+The `bench` binary seeds raw actions to measure dequeue/execute/ack throughput. Use `bench_instances` for an end-to-end workflow run (queueing and executing full workflow instances via the scheduler) without installing a separate `rappel-worker` binary—the harness shells out to `uv run python -m rappel.worker` automatically:
+
+```bash
+$ cargo run --bin bench_instances -- \
+  --instances 200 \
+  --batch-size 4 \
+  --payload-size 1024 \
+  --concurrency 64 \
+  --workers 4
+```
+```
+
+Add `--json` to the parser if you prefer JSON output.

rappel-0.5.1.dist-info/RECORD

@@ -0,0 +1,32 @@
+proto/ast_pb2.py,sha256=W3b0smmQe7cHotEj9eVWo5iFJLG8snzh1URa8_3oYis,12866
+proto/ast_pb2.pyi,sha256=b0a2vy6QoeW1YCMOy4_VLxd2Pj_P-WbK1uwZ99BEkN4,47381
+proto/ast_pb2_grpc.py,sha256=KJj-_ba1ZxWWYph-D7UShEDiZ2g3HrjffT-Ch9wtir0,868
+proto/ast_pb2_grpc.pyi,sha256=ItuwUBKMrD0GfjDvwsarqytfyBpzDqQ_TMiJ0FNIoog,466
+proto/messages_pb2.py,sha256=MdksC6bnrrsgCC-8FDMFsrpzbGAJvSuu7XM71C4epQw,12650
+proto/messages_pb2.pyi,sha256=Wb65R4JmyWQYsoG2pgE4SrR7Sf7drWuGjDM2GpM1P_0,39759
+proto/messages_pb2_grpc.py,sha256=6akfrXSv9w5oaWmMcnxUFilM5p_fIEIowqueUp3bAqk,15846
+proto/messages_pb2_grpc.pyi,sha256=aN1cqB6D4Cn8npN_bh9Rz-v0VXmljsQYjf3zCM5FjrU,12322
+rappel/__init__.py,sha256=LKQpsR-Pj6wbu02DYYLr6lUTgsWDznQ8GIzu_ezyeL0,1335
+rappel/actions.py,sha256=ayfsBMU4rXR8Qnz6Sl7D01M7nGz42fr3Sf0c9yM2NPk,3847
+rappel/bridge.py,sha256=wPBNsjK1iWqTZgerKbbMz3Z_UA5GPavFk_N4H9dniQc,8128
+rappel/dependencies.py,sha256=W9GpaLFc1vfQ3TsIMjvebOICTpQ0-tNInURmPt7BjIY,5640
+rappel/exceptions.py,sha256=MvX6HUxjMcHBq-pEnKRubhdMwA8irSiWvm3VVyyjn5Y,337
+rappel/formatter.py,sha256=qLmnVa_hGjv6ydw4lDVq3n6FMs-Rpk9Zz9AqW23IGII,3113
+rappel/ir_builder.py,sha256=W2KGHkB-8HxNQybFN_y4FxgH5FquLjTAkTfBtVOT8t4,118064
+rappel/logger.py,sha256=NXK2GM4k_zPFG9yUJKjR9B3UZth2QWc2nts9IQU1s2Q,1118
+rappel/registry.py,sha256=-bLrFPcLNYYKTjqPMWuerSuwkOpGqmzzEsXiuPPrcZA,3526
+rappel/schedule.py,sha256=8YhhFT4iwagiZsCyHop7BsX0MmCpsbjFiMrjsokcYr0,10923
+rappel/serialization.py,sha256=1p-Qp_5nxlRGF9-0c2ZlVnFxI5TVodw1HFv79RBO8MA,9891
+rappel/worker.py,sha256=W-zTY25cR72jX-ubVmNipFiR52EDmcamndoFmAj4DOw,6836
+rappel/workflow.py,sha256=oks205Lb8_A581v2DlawbYf98duQo-amgtcczItKvM8,8061
+rappel/workflow_runtime.py,sha256=fdFQEh6uJ2wOfevS7x_ZtTqAXpufGchJnt950x5vpfQ,9038
+rappel/bin/boot-rappel-singleton,sha256=i-PLDg_mq-2yE3jr_XbVIsEeyjBffTeyuU7-tq8a9qY,6431168
+rappel/bin/rappel-bridge,sha256=b2SOggxeugwb-beshDm6EYZWQEXTrbBbY0Tpb8h2mng,11047152
+rappel/bin/start-workers,sha256=vFr1ifMojZJv0KbtFp_8feUtH4F9kY1ppS36JeyVSzo,19272296
+rappel-0.5.1.dist-info/METADATA,sha256=l8zTZgAgJZYQfUhaFcPVgdSI0w7ZFGAyen02d4oMe0s,15738
+rappel-0.5.1.dist-info/entry_points.txt,sha256=h9D-AufOUWpdE7XjnyZyQCc-kER-ZIKj1Jryc1JNL_I,53
+rappel-0.5.1.dist-info/RECORD,,
+rappel-0.5.1.data/scripts/rappel-bridge,sha256=b2SOggxeugwb-beshDm6EYZWQEXTrbBbY0Tpb8h2mng,11047152
+rappel-0.5.1.data/scripts/boot-rappel-singleton,sha256=i-PLDg_mq-2yE3jr_XbVIsEeyjBffTeyuU7-tq8a9qY,6431168
+rappel-0.5.1.data/scripts/start-workers,sha256=vFr1ifMojZJv0KbtFp_8feUtH4F9kY1ppS36JeyVSzo,19272296
+rappel-0.5.1.dist-info/WHEEL,sha256=74UJPlMKWRubwKveoWxggMGihpugjX6MX_YPU_nD8sg,107

rappel-0.5.1.dist-info/WHEEL

@@ -0,0 +1,4 @@
+Wheel-Version: 1.0
+Generator: hatchling 1.28.0
+Root-Is-Purelib: false
+Tag: py3-none-manylinux_2_39_aarch64

rappel-0.5.1.dist-info/entry_points.txt

@@ -0,0 +1,2 @@
+[console_scripts]
+rappel-worker = rappel.worker:main