Metadata-Version: 2.5
Name: glyff-file-store
Version: 0.16.0
Summary: File-based execution backend for glyff.
License: MIT License
        
        Copyright (c) 2026 nueruyu
        
        Permission is hereby granted, free of charge, to any person obtaining a copy
        of this software and associated documentation files (the "Software"), to deal
        in the Software without restriction, including without limitation the rights
        to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
        copies of the Software, and to permit persons to whom the Software is
        furnished to do so, subject to the following conditions:
        
        The above copyright notice and this permission notice shall be included in all
        copies or substantial portions of the Software.
        
        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
        IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
        FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
        AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
        LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
        OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
        SOFTWARE.
License-File: LICENSE
Classifier: Development Status :: 3 - Alpha
Classifier: Framework :: AsyncIO
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Typing :: Typed
Requires-Python: >=3.11
Requires-Dist: filelock>=3.15
Requires-Dist: glyff>=0.14.0
Description-Content-Type: text/markdown

# glyff-file-store

File-backed `ExecutionRepository` implementation for
[glyff](https://pypi.org/project/glyff/).

This is the human-readable **debug** backend: `JsonFileBackend` bundles a
file-backed execution repository and transaction provider, storing executions
in a single pretty-printed JSON map that is rewritten atomically on each
commit.

For the durable production backend, see
[`glyff-sqlite`](https://pypi.org/project/glyff-sqlite/).

## Install

```bash
pip install glyff-file-store
```

This package depends on `glyff>=0.14.0` and `filelock>=3.15`.

## Public API

| Name                      | Description                                               |
| ------------------------- | --------------------------------------------------------- |
| `JsonFileBackend`         | Bundle exposing the store's collaborators.                |
| `FileExecutionRepository` | Debug repository writing pretty-printed JSON.             |
| `FileTransactionProvider` | Transaction provider for the file backend.                |

Construct it with a `base_dir`; it holds every session written under it:

```python
from glyff_file_store import JsonFileBackend

backend = JsonFileBackend(base_dir=".sessions")
```

The underlying `FileClient` is internal and not part of the public API.

## JSON debug format

Everything the store holds lives in one pretty-printed, key-sorted document at
`<base_dir>/glyff.json`, nested by session id:

```json
{
  "format_version": 1,
  "sessions": {
    "orders": {
      "domain_versions": {
        "com.example.payments": "3"
      },
      "executions": {}
    }
  }
}
```

`format_version` is glyff's own, so a store written by an incompatible build is
refused rather than misread; `domain_versions` holds one version per domain the
session has entered, each claimed by whichever process entered it first.

Execution results and metadata are stored as embedded JSON values, so
serializers used with this backend must produce JSON text. Canonical arguments
are stored as a JSON *string* instead: the execution's key is the digest of
those exact bytes, so they are kept verbatim rather than re-encoded.

The whole document is read on access and rewritten on every commit, which is
what keeps it readable and what makes it unsuitable for high-throughput or
large-scale use.

## Commit atomicity

A commit reads the document, applies the transaction's staged updates, and
replaces the file in one `os.replace`, so it is all-or-nothing however many
sessions it touched. A crash can only strand a temporary beside the document,
never leave the document itself half-written; the next open clears it.

## Concurrency

Commits and version claims are serialized across the processes sharing a
`base_dir`, through a `.glyff.lock` file beside the document. Reads take no
lock: a replacement is atomic, so a read sees either the whole old document or
the whole new one.

## Status

Pre-1.0 — the API is unstable and will change.

## License

MIT
