xtr-cli 5.0.0__tar.gz → 5.1.0__tar.gz

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: xtr-cli
-Version: 5.0.0
+Version: 5.1.0
 Summary: Scaffolds a new xtr application — a console application or a web application — in one command, and serves it.
 Keywords: scaffold,new project,template,console,web,xtr-dependency-injection
 Author: Xterr
@@ -139,7 +139,7 @@ refused before anything is written.
 2. `uv add` the template's packages and the add-ons; every unversioned xtr requirement is pinned
    to this tool's major version, so the files and the packages are from the same release.
 3. `uv add --dev` the tools: `xtr-recipes`, `pytest`, `ruff`, `basedpyright`, `ty`.
-4. `uv run xtr-recipes recipes:sync` — each package's recipe writes `<app>/bundles.py`, its
+4. `uv run xtr-recipes recipes:sync` — each package's recipe writes `<app>/config/bundles.py`, its
    configuration files, its `.env` and `.gitignore` blocks, and `xtr.lock`; the steps it cannot
    make are printed.
 5. `git init`; nothing is committed.
@@ -229,13 +229,13 @@ way it would for a package added later with `xtr-recipes recipes:add`.
 
 | Add-on | Installs | Variants |
 |---|---|---|
-| `orm` | `xtr-orm` | `sqlite` (default), `postgres`, `mysql` |
-| `messenger` | `xtr-messenger` | `amqp`, `pydantic` |
+| `orm` | `xtr-orm` | `postgres` (default), `sqlite`, `mysql` |
+| `messenger` | `xtr-messenger` | `amqp` (default), `pydantic` |
 | `scheduler` | `xtr-scheduler[cron]` | |
 | `event-dispatcher` | `xtr-event-dispatcher` | |
 | `cache` | `xtr-cache` | `redis` |
 | `lock` | `xtr-lock` | `redis` |
-| `rate-limiter` | `xtr-rate-limiter` | `redis` |
+| `rate-limiter` | `xtr-rate-limiter` | |
 | `storage` | `xtr-storage` | `s3`, `gcs` |
 | `http-client` | `xtr-http-client` | `http2` |
 | `security` | `xtr-security` — `webapp` only | |
@@ -247,10 +247,11 @@ Variants only pick third-party backends. Integrations between xtr packages turn
 installed: choose `orm` beside `oauth2` to keep its clients in a database, `http-client` beside
 `webhook` to send webhooks, `rate-limiter` beside `http-client` to pace requests.
 
-`jwt` boots without a key and signs nothing until one is there: run
-`uv run <name> jwt:generate-keypair --kid jwt --output-dir secrets` for development, and mount
-the deployment's own key in production. No key is ever minted for you.
-`oauth2` likewise issues nothing until its key pair, encryption key and issuer are configured.
+`jwt` and `oauth2` each have their recipe mint a development signing key under `secrets/`,
+encrypted with a pass phrase it generates in `.env` — and, for `oauth2`, the encryption key too.
+The keys are ignored: another checkout runs `uv run xtr-recipes recipes:install <package>` to
+mint its own, and production mounts the deployment's own key and sets its own secrets. `oauth2`
+still issues nothing until its issuer is configured.
 
 Variants follow the name after `:`, joined with `+`: `orm:sqlite+postgres`. A name alone takes
 the defaults; `messenger:` picks none. Asked interactively, an add-on with variants is followed by

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/README.md

@@ -118,7 +118,7 @@ refused before anything is written.
 2. `uv add` the template's packages and the add-ons; every unversioned xtr requirement is pinned
    to this tool's major version, so the files and the packages are from the same release.
 3. `uv add --dev` the tools: `xtr-recipes`, `pytest`, `ruff`, `basedpyright`, `ty`.
-4. `uv run xtr-recipes recipes:sync` — each package's recipe writes `<app>/bundles.py`, its
+4. `uv run xtr-recipes recipes:sync` — each package's recipe writes `<app>/config/bundles.py`, its
    configuration files, its `.env` and `.gitignore` blocks, and `xtr.lock`; the steps it cannot
    make are printed.
 5. `git init`; nothing is committed.
@@ -208,13 +208,13 @@ way it would for a package added later with `xtr-recipes recipes:add`.
 
 | Add-on | Installs | Variants |
 |---|---|---|
-| `orm` | `xtr-orm` | `sqlite` (default), `postgres`, `mysql` |
-| `messenger` | `xtr-messenger` | `amqp`, `pydantic` |
+| `orm` | `xtr-orm` | `postgres` (default), `sqlite`, `mysql` |
+| `messenger` | `xtr-messenger` | `amqp` (default), `pydantic` |
 | `scheduler` | `xtr-scheduler[cron]` | |
 | `event-dispatcher` | `xtr-event-dispatcher` | |
 | `cache` | `xtr-cache` | `redis` |
 | `lock` | `xtr-lock` | `redis` |
-| `rate-limiter` | `xtr-rate-limiter` | `redis` |
+| `rate-limiter` | `xtr-rate-limiter` | |
 | `storage` | `xtr-storage` | `s3`, `gcs` |
 | `http-client` | `xtr-http-client` | `http2` |
 | `security` | `xtr-security` — `webapp` only | |
@@ -226,10 +226,11 @@ Variants only pick third-party backends. Integrations between xtr packages turn
 installed: choose `orm` beside `oauth2` to keep its clients in a database, `http-client` beside
 `webhook` to send webhooks, `rate-limiter` beside `http-client` to pace requests.
 
-`jwt` boots without a key and signs nothing until one is there: run
-`uv run <name> jwt:generate-keypair --kid jwt --output-dir secrets` for development, and mount
-the deployment's own key in production. No key is ever minted for you.
-`oauth2` likewise issues nothing until its key pair, encryption key and issuer are configured.
+`jwt` and `oauth2` each have their recipe mint a development signing key under `secrets/`,
+encrypted with a pass phrase it generates in `.env` — and, for `oauth2`, the encryption key too.
+The keys are ignored: another checkout runs `uv run xtr-recipes recipes:install <package>` to
+mint its own, and production mounts the deployment's own key and sets its own secrets. `oauth2`
+still issues nothing until its issuer is configured.
 
 Variants follow the name after `:`, joined with `+`: `orm:sqlite+postgres`. A name alone takes
 the defaults; `messenger:` picks none. Asked interactively, an add-on with variants is followed by

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "xtr-cli"
-version = "5.0.0"
+version = "5.1.0"
 description = "Scaffolds a new xtr application — a console application or a web application — in one command, and serves it."
 readme = "README.md"
 requires-python = ">=3.11"

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/pyproject.toml.orig

@@ -1,6 +1,6 @@
 [project]
 name = "xtr-cli"
-version = "5.0.0"
+version = "5.1.0"
 description = "Scaffolds a new xtr application — a console application or a web application — in one command, and serves it."
 readme = "README.md"
 requires-python = ">=3.11"

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/src/xtr_cli/add_on_catalog.py

@@ -22,7 +22,8 @@ _SHIPPED = (
         "xtr-orm",
         (),
         ("sqlite", "postgres", "mysql"),
-        ("sqlite",),
+        # The recipe's DATABASE_URL is a PostgreSQL one, so its driver is the default.
+        ("postgres",),
         "database drivers",
     ),
     AddOn(
@@ -31,7 +32,8 @@ _SHIPPED = (
         "xtr-messenger",
         (),
         ("amqp", "pydantic"),
-        (),
+        # The recipe's MESSENGER_DSN is a RabbitMQ one, so its transport is the default.
+        ("amqp",),
         "transports and serializers",
     ),
     AddOn(
@@ -55,15 +57,9 @@ _SHIPPED = (
         "backends",
     ),
     AddOn("lock", "Locks around shared resources.", "xtr-lock", (), ("redis",), (), "stores"),
-    AddOn(
-        "rate-limiter",
-        "Limits on how often anything may happen.",
-        "xtr-rate-limiter",
-        (),
-        ("redis",),
-        (),
-        "stores",
-    ),
+    # No store is asked for: the recipe writes no configuration that would use
+    # one, so a project picks its store where it names its limiters.
+    AddOn("rate-limiter", "Limits on how often anything may happen.", "xtr-rate-limiter"),
     AddOn(
         "storage",
         "Files on local disk, in memory or in object stores.",

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/src/xtr_cli/templates/cli/files/README.md.tmpl

@@ -20,7 +20,9 @@ The environment is read from `.env`, then `.env.local`, then `.env.<APP_ENV>` an
 src/${app}/
 ├── __main__.py        the console entry point
 ├── kernel.py          the kernel every entry point builds, and the environment loader
-├── bundles.py         the active bundles — written by xtr-recipes
+├── config/
+│   ├── bundles.py     the active bundles — written by xtr-recipes
+│   └── packages/      one @configure module per bundle
 └── command/           the console commands
 ```
 

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/src/xtr_cli/templates/cli/files/app/kernel.py.tmpl

@@ -19,7 +19,7 @@ PROJECT_DIR: Final = Path(__file__).resolve().parents[2]
 
 kernel: Final = Kernel(
     "${app}",
-    # The bundles are read from ${app}.bundles.BUNDLES; the environment from APP_ENV.
+    # The bundles are read from ${app}.config.bundles.BUNDLES; the environment from APP_ENV.
     allowed_envs=("dev", "test", "prod"),
 )
 

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/src/xtr_cli/templates/webapp/files/README.md.tmpl

@@ -21,7 +21,9 @@ The environment is read from `.env`, then `.env.local`, then `.env.<APP_ENV>` an
 src/${app}/
 ├── __main__.py        the console entry point
 ├── kernel.py          the kernel every entry point builds, and the environment loader
-├── bundles.py         the active bundles — written by xtr-recipes
+├── config/
+│   ├── bundles.py     the active bundles — written by xtr-recipes
+│   └── packages/      one @configure module per bundle
 ├── command/           the console commands
 └── web/
     ├── __main__.py    the web entry point

xtr_cli-5.1.0/src/xtr_cli/templates/webapp/files/app/config/__init__.py.tmpl

@@ -0,0 +1,5 @@
+"""The application's configuration: the bundle list, each bundle's configuration, the routes."""
+
+from __future__ import annotations
+
+__all__: list[str] = []

xtr_cli-5.1.0/src/xtr_cli/templates/webapp/files/app/config/packages/__init__.py.tmpl

@@ -0,0 +1,5 @@
+"""Configuration modules: one ``@configure`` function per bundle the application changes."""
+
+from __future__ import annotations
+
+__all__: list[str] = []

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/src/xtr_cli/templates/webapp/files/app/kernel.py.tmpl

@@ -19,7 +19,7 @@ PROJECT_DIR: Final = Path(__file__).resolve().parents[2]
 
 kernel: Final = Kernel(
     "${app}",
-    # The bundles are read from ${app}.bundles.BUNDLES; the environment from APP_ENV.
+    # The bundles are read from ${app}.config.bundles.BUNDLES; the environment from APP_ENV.
     allowed_envs=("dev", "test", "prod"),
     # ${app}.web.app builds the web application as it is imported, and that application is
     # served from this very kernel: scanning it would import it while the kernel builds.

{xtr_cli-5.0.0 → xtr_cli-5.1.0}/src/xtr_cli/templates/webapp/template.toml

@@ -28,7 +28,8 @@ dev = ["xtr-recipes", "pytest", "httpx", "ruff", "basedpyright", "ty"]
 "src/${app}/command/__init__.py" = "files/app/command/__init__.py.tmpl"
 "src/${app}/command/hello_command.py" = "files/app/command/hello_command.py.tmpl"
 "src/${app}/config/__init__.py" = "files/app/config/__init__.py.tmpl"
-"src/${app}/config/http_kernel.py" = "files/app/config/http_kernel.py.tmpl"
+"src/${app}/config/packages/__init__.py" = "files/app/config/packages/__init__.py.tmpl"
+"src/${app}/config/packages/http_kernel.py" = "files/app/config/packages/http_kernel.py.tmpl"
 "src/${app}/web/__init__.py" = "files/app/web/__init__.py.tmpl"
 "src/${app}/web/__main__.py" = "files/app/web/__main__.py.tmpl"
 "src/${app}/web/app.py" = "files/app/web/app.py.tmpl"

xtr_cli-5.0.0/src/xtr_cli/templates/webapp/files/app/config/__init__.py.tmpl

@@ -1,5 +0,0 @@
-"""The application's bundle configuration: one ``@configure`` function per bundle it changes."""
-
-from __future__ import annotations
-
-__all__: list[str] = []