jero 0.0.2__tar.gz

jero-0.0.2/.github/actions/setup-python-env/action.yml

@@ -0,0 +1,30 @@
+name: "Setup Python Environment"
+description: "Set up Python environment for the given Python version"
+
+inputs:
+  python-version:
+    description: "Python version to use"
+    required: true
+    default: "3.14"
+  uv-version:
+    description: "uv version to use"
+    required: true
+    default: "0.10.12"
+
+runs:
+  using: "composite"
+  steps:
+    - uses: actions/setup-python@v5
+      with:
+        python-version: ${{ inputs.python-version }}
+
+    - name: Install uv
+      uses: astral-sh/setup-uv@v6
+      with:
+        version: ${{ inputs.uv-version }}
+        enable-cache: 'true'
+        cache-suffix: ${{ matrix.python-version }}
+
+    - name: Install Python dependencies
+      run: uv sync --frozen
+      shell: bash

jero-0.0.2/.github/workflows/main.yml

@@ -0,0 +1,70 @@
+name: Main
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    types: [opened, synchronize, reopened, ready_for_review]
+
+jobs:
+  quality:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out
+        uses: actions/checkout@v4
+
+      - uses: actions/cache@v4
+        with:
+          path: ~/.cache/pre-commit
+          key: pre-commit-${{ hashFiles('.pre-commit-config.yaml') }}
+
+      - name: Set up the environment
+        uses: ./.github/actions/setup-python-env
+
+      - name: Run checks
+        run: |
+          uv lock --locked
+          uv run prek run -a
+
+  tests-and-type-check:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python-version: ["3.14"]
+      fail-fast: false
+    defaults:
+      run:
+        shell: bash
+    steps:
+      - name: Check out
+        uses: actions/checkout@v4
+
+      - name: Set up the environment
+        uses: ./.github/actions/setup-python-env
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Run tests
+        run: uv run python -m pytest tests --cov --cov-config=pyproject.toml --cov-report=xml
+
+      - name: Check typing
+        run: uv run pyright
+
+      - name: Upload coverage reports to Codecov with GitHub Action on Python 3.14
+        uses: codecov/codecov-action@v4
+        if: ${{ matrix.python-version == '3.14' }}
+        env:
+          CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
+
+  check-docs:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out
+        uses: actions/checkout@v4
+
+      - name: Set up the environment
+        uses: ./.github/actions/setup-python-env
+
+      - name: Check if documentation can be built
+        run: uv run zensical build -s

jero-0.0.2/.github/workflows/on-release-main.yml

@@ -0,0 +1,69 @@
+name: release-main
+
+on:
+  release:
+    types: [published]
+
+jobs:
+
+  publish:
+    runs-on: ubuntu-latest
+    # Trusted Publishing (OIDC) — no PyPI token needed. The environment name
+    # must match the one configured on the PyPI publisher ("pypi").
+    environment:
+      name: pypi
+      url: https://pypi.org/p/jero
+    permissions:
+      id-token: write
+    steps:
+      - name: Check out
+        uses: actions/checkout@v4
+
+      - name: Set up the environment
+        uses: ./.github/actions/setup-python-env
+
+      # pyproject.toml is the single source of truth for the version; the release
+      # tag must match it exactly, or the release fails here (no silent drift).
+      - name: Verify the release tag matches the pyproject version
+        run: |
+          version="$(python -c 'import tomllib, pathlib; print(tomllib.loads(pathlib.Path("pyproject.toml").read_text())["project"]["version"])')"
+          tag="${{ github.event.release.tag_name }}"
+          if [ "$version" != "$tag" ]; then
+            echo "::error::release tag '$tag' does not match pyproject version '$version' — bump 'version' in pyproject.toml to match the tag"
+            exit 1
+          fi
+
+      - name: Build package
+        run: uv build
+
+      - name: Publish package
+        run: uv publish
+
+  deploy-docs:
+    needs: publish
+    permissions:
+      contents: read
+      pages: write
+      id-token: write
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out
+        uses: actions/checkout@v4
+
+      - name: Set up the environment
+        uses: ./.github/actions/setup-python-env
+
+      - name: Build documentation
+        run: uv run zensical build --clean
+
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v4
+        with:
+          path: site
+
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

jero-0.0.2/.github/workflows/validate-codecov-config.yml

@@ -0,0 +1,15 @@
+name: validate-codecov-config
+
+on:
+  pull_request:
+    paths: [codecov.yaml]
+  push:
+    branches: [main]
+
+jobs:
+  validate-codecov-config:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Validate codecov configuration
+        run: curl -sSL --fail-with-body --data-binary @codecov.yaml https://codecov.io/validate

jero-0.0.2/.gitignore

@@ -0,0 +1,211 @@
+docs/source
+
+# From https://raw.githubusercontent.com/github/gitignore/main/Python.gitignore
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs/zensical documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer,
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/

jero-0.0.2/.pre-commit-config.yaml

@@ -0,0 +1,41 @@
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: "v6.0.0"
+    hooks:
+      - id: check-case-conflict
+      - id: check-merge-conflict
+      - id: check-toml
+      - id: check-yaml
+      - id: check-json
+      - id: pretty-format-json
+        args: [--autofix, --no-sort-keys]
+      - id: end-of-file-fixer
+      - id: trailing-whitespace
+
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: "v0.15.15"
+    hooks:
+      - id: ruff-check
+        args: [--exit-non-zero-on-fix]
+      - id: ruff-format
+
+  - repo: local
+    hooks:
+      - id: pyright
+        name: pyright
+        entry: uv run pyright
+        language: system
+        types: [python]
+        pass_filenames: false
+
+      - id: deptry
+        name: deptry
+        entry: uv run deptry .
+        language: system
+        pass_filenames: false
+
+      - id: pylint
+        name: pylint
+        entry: uv run pylint
+        language: system
+        types: [python]

jero-0.0.2/AGENTS.md

@@ -0,0 +1,128 @@
+# AGENTS.md
+
+## jero
+
+An opinionated, msgspec-first ASGI web framework (Python 3.14). The goal is a
+framework that is **both** very fast **and** a joy to build on — achieved by
+being aggressively opinionated rather than flexible.
+
+## Design philosophy (three pillars, all non-negotiable)
+
+1. **Speed.** All introspection happens once, at wiring time; the per-request
+   path is just dict lookup → msgspec decode → call → encode, nothing else.
+   Benchmarks co-lead blacksheep and well outpace FastAPI. Never add per-request
+   work — resolve it at startup.
+
+2. **Opinionated, scaffolded DX.** There is *one blessed way* to do each thing,
+   and the framework encodes the expertise so the developer can't get it wrong
+   (lifecycle, REST semantics, validation, dependency wiring). Contracts are
+   checked at startup and fail loud with a precise `WiringError` — never
+   silently at runtime. The aim: there's a framework answer to "how do I do X?"
+   so that question never reaches code review.
+
+3. **Strict, expressive typing — not optional.** Everything is fully, statically
+   typed under pyright-strict. If you don't like typing, this is not your
+   framework. Types are not decoration — they *are* the contract (the binding,
+   the `WiringError`s) and, soon, the source of the OpenAPI spec (see roadmap).
+   Every design decision must produce precise static types; prefer rich,
+   self-documenting generics (`-> NDJSONStreamingResponse[Movie]`,
+   `BaseApp[Factory]`) over loose annotations. A feature that can't be expressed
+   in exact static types isn't done. **Never** reach for `Any` or untyped
+   `dict`/`bytes` I/O to dodge a type — it punches a hole in both the contract
+   and the generated docs. Hold this standard in every future design session.
+
+These pull against each other constantly; keep all three in mind on every change.
+
+## Working on jero
+
+- **Read `style-guide.md` before writing code** — project conventions beyond what
+  ruff/pyright enforce (dataclasses, no globals, member ordering, no nested
+  funcs/classes, etc.).
+- pyright **strict** and ruff must stay clean; tests must pass. `task pyright`,
+  `task ruff`, `task test` — or run everything at once with `task check`.
+- **Never suppress a lint/type error to make it pass — always fix the code.**
+  Adding *any* ignore/disable — `# pylint: disable=…`, `# noqa`, `# type: ignore`,
+  `# pyright: ignore`, a `disable`/`ignore`/`per-file-ignores` entry in config, a
+  `deptry` ignore, etc. — is **forbidden without explicit human approval first**.
+  Ask, with the specific rule and why a code fix won't do; apply it only once the
+  human says yes. This applies to *every* tool, every time — no exceptions, no
+  "obviously fine" cases.
+- For framework-level / design changes, **discuss the design first** — don't just
+  implement. Give options + a recommendation, then build once decided.
+- **Testing stance:** tests run only through the public boundary — `TestClient`
+  against demo apps in `tests/`. **Do not unit-test `jero/` internals directly**;
+  they're covered transitively. This is deliberate (style-guide rule 7, and it
+  lets the internals be refactored freely — which they are, often). Don't "fix"
+  the absence of internal tests. Revisit only once the internals stabilize
+  (approaching a stable release), and even then only a thin layer for the
+  intricate *pure* helpers (`_parse_template`/`_route_segments`, the
+  `__orig_bases__` factory-type extraction, SSE/NDJSON formatting).
+
+## The contract (how apps are built)
+
+- **`Resource`** — a class with CRUD methods: `create` / `read_one` / `read_many`
+  / `update` / `partial_update` / `delete` → POST / GET(item) / GET(collection)
+  / PUT / PATCH / DELETE.
+- **`Endpoint`** — bare verbs (`get`/`post`/…) for non-resource routes (health,
+  webhooks, actions). One path per Endpoint.
+- Handler args bind **by name**, each a msgspec Struct: `json`, `content` (raw
+  bytes, exclusive with `json`), `params` (query), `path` (URL template slots),
+  `headers`, `user` (auth result). Return a Struct, `list[Struct]`, `bytes`, or a
+  `BytesResponse`/`JSONResponse`/streaming response.
+- **A JSON body is always a Struct — never a raw `dict`.** The
+  `@api.get(...) → return {"a": 1}` idiom is gone: a `dict`/blob return is a
+  `WiringError` at startup. JSON in and out is a typed Struct, every time — that's
+  what gives it validation *and* a schema for the OpenAPI spec. No exceptions.
+- **Auth**: an object with `authenticate(headers: Struct) -> UserStruct`; the
+  user type is checked against handlers at startup.
+- **Wiring / DI**: there is **no DI container** — and that's deliberate, not a
+  gap. You hand-wire classes in `_wire` (subclass `BaseApp[Factory]`, linear
+  async, no yield); a dependency is just a constructor argument. The one thing
+  the language doesn't give you free — lifecycle — is what the framework adds:
+  open resources with `self._aenter` / `self._enter` (the app owns two exit
+  stacks, closed in reverse at shutdown, even on partial failure), and a
+  `BaseFactory` (stacks injected) groups construction. Past that there's nothing
+  to "resolve." Per-request resources are an `async with` inside the handler.
+  Do **not** add an injection/resolver system.
+- REST error semantics throughout (404/400/422/401/405, auto HEAD + OPTIONS);
+  camelCase on the wire via msgspec `rename`.
+- **Naming convention**: foundations you extend once are `Base*` (`BaseApp`,
+  `BaseFactory`); the request vocabulary you implement many specific subclasses of
+  stays plain (`Resource`, `Endpoint`).
+
+## Layout
+
+- `jero/core.py` — the framework. `jero/testing.py` — sync in-process `TestClient`
+  + `FactoryHarness`. `jero/forms.py` / `jero/streaming.py` — form parts and
+  streaming response types.
+- Runtime deps are intentionally sparse: `msgspec` for typed validation/JSON and
+  `python-multipart` for buffered `multipart/form-data` parsing.
+- `tests/` — pytest suite driven through `TestClient` against demo apps in
+  `tests/demo_app.py`.
+- `plans/` — design plans for not-yet-built features (e.g. `streaming.md`,
+  `forms.md`), staged for review before implementation.
+- `bugs/` — one markdown note per bug, tracked in `bugs/README.md` (the manifest).
+  **Never delete a fixed bug note** — flip its row to `Done` in the manifest and
+  update the Open/Done counts. A fix isn't done until it has a regression test.
+- Demo apps and the competitor/benchmark harness live in a **separate repo**, not here.
+
+## Status & sharp edges
+
+- **Built**: routing + path-param templates, Resource/Endpoint, all binding
+  sources, auth, REST semantics, response kinds, `BaseApp`/`BaseFactory`
+  lifecycle, `TestClient`, the test suite.
+- **Performance (validated natively)**: on the authed write path
+  (`POST /movies` — bearer auth + JSON decode + encode + 201, C=200), jero ≈
+  blacksheep (~43k req/s, a tie), ~2× litestar, ~3× robyn, ~6× idiomatic FastAPI.
+  Tight unimodal latency — trustworthy. (The benchmark harness lives in a
+  separate repo; run natively rather than under emulation for real figures.)
+- **Unbuilt**: custom status codes, `Location` header on 201. Minor polish: the
+  factory's `es`/`aes` stack injection matches by name with no startup check — a
+  `WiringError` on an unrecognized param would close that.
+- **Roadmap**: auto-generated **OpenAPI spec + live, hosted docs**. This is the
+  reason every endpoint must be statically typed end to end — the schema is
+  *derived from the types* (Struct sources, typed returns including generics like
+  `NDJSONStreamingResponse[Movie]`), with no runtime guessing. Any feature that
+  escapes static typing won't appear in the spec, so don't add one.
+- **Untested**: no non-trivial real app has been built on it yet — that's where
+  the opinions (pagination, streaming, cross-cutting concerns) get stress-tested.

jero-0.0.2/CONTRIBUTING.md

@@ -0,0 +1,126 @@
+# Contributing to `jero`
+
+Contributions are welcome, and they are greatly appreciated!
+Every little bit helps, and credit will always be given.
+
+You can contribute in many ways:
+
+# Types of Contributions
+
+## Report Bugs
+
+Report bugs at https://github.com/RogerThomas/jero/issues
+
+If you are reporting a bug, please include:
+
+- Your operating system name and version.
+- Any details about your local setup that might be helpful in troubleshooting.
+- Detailed steps to reproduce the bug.
+
+## Fix Bugs
+
+Look through the GitHub issues for bugs.
+Anything tagged with "bug" and "help wanted" is open to whoever wants to implement a fix for it.
+
+## Implement Features
+
+Look through the GitHub issues for features.
+Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.
+
+## Write Documentation
+
+jero could always use more documentation, whether as part of the official docs, in docstrings, or even on the web in blog posts, articles, and such.
+
+## Submit Feedback
+
+The best way to send feedback is to file an issue at https://github.com/RogerThomas/jero/issues.
+
+If you are proposing a new feature:
+
+- Explain in detail how it would work.
+- Keep the scope as narrow as possible, to make it easier to implement.
+- Remember that this is a volunteer-driven project, and that contributions
+  are welcome :)
+
+# Get Started!
+
+Ready to contribute? Here's how to set up `jero` for local development.
+Please note this documentation assumes you already have `uv` and `Git` installed and ready to go.
+
+1. Fork the `jero` repo on GitHub.
+
+2. Clone your fork locally:
+
+```bash
+cd <directory_in_which_repo_should_be_created>
+git clone git@github.com:YOUR_NAME/jero.git
+```
+
+3. Now we need to install the environment. Navigate into the directory
+
+```bash
+cd jero
+```
+
+Then, install and activate the environment with:
+
+```bash
+uv sync
+```
+
+4. Install pre-commit to run linters/formatters at commit time:
+
+```bash
+uv run pre-commit install
+```
+
+5. Create a branch for local development:
+
+```bash
+git checkout -b name-of-your-bugfix-or-feature
+```
+
+Now you can make your changes locally.
+
+6. Don't forget to add test cases for your added functionality to the `tests` directory.
+
+7. When you're done making changes, check that your changes pass the formatting tests.
+
+```bash
+make check
+```
+
+Now, validate that all unit tests are passing:
+
+```bash
+make test
+```
+
+9. Before raising a pull request you should also run tox.
+   This will run the tests across different versions of Python:
+
+```bash
+tox
+```
+
+This requires you to have multiple versions of python installed.
+This step is also triggered in the CI/CD pipeline, so you could also choose to skip this step locally.
+
+10. Commit your changes and push your branch to GitHub:
+
+```bash
+git add .
+git commit -m "Your detailed description of your changes."
+git push origin name-of-your-bugfix-or-feature
+```
+
+11. Submit a pull request through the GitHub website.
+
+# Pull Request Guidelines
+
+Before you submit a pull request, check that it meets these guidelines:
+
+1. The pull request should include tests.
+
+2. If the pull request adds functionality, the docs should be updated.
+   Put your new functionality into a function with a docstring, and add the feature to the list in `README.md`.