docker-devkit 0.1.20__tar.gz → 0.1.22__tar.gz

{docker_devkit-0.1.20 → docker_devkit-0.1.22}/.github/workflows/ci.yml

@@ -10,6 +10,9 @@ concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
   cancel-in-progress: true
 
+env:
+  PYTHON_DEVKIT_VERSION: "0.1.13"
+
 jobs:
   check:
     runs-on: ubuntu-latest
@@ -23,4 +26,4 @@ jobs:
           enable-cache: true
 
       - name: Preflight
-        run: uvx --from python-devkit==0.1.5 preflight-python
+        run: uvx --from python-devkit==${PYTHON_DEVKIT_VERSION} preflight-python

{docker_devkit-0.1.20 → docker_devkit-0.1.22}/.github/workflows/release.yml

@@ -17,6 +17,8 @@ jobs:
     permissions:
       contents: write
       id-token: write
+    env:
+      RELEASE_DEVKIT_VERSION: "0.1.24"
     steps:
       - uses: actions/checkout@v5
         with:
@@ -28,4 +30,4 @@ jobs:
       - uses: astral-sh/setup-uv@v7
 
       - name: Publish
-        run: uvx --from release-devkit==0.1.18 publish-stable --config release-devkit.json
+        run: uvx --from release-devkit==${RELEASE_DEVKIT_VERSION} publish-stable --config release-devkit.yaml

{docker_devkit-0.1.20 → docker_devkit-0.1.22}/AGENTS.md

@@ -6,11 +6,11 @@
 
 The package is `docker_devkit` (src-layout under `src/docker_devkit/`); all dependencies resolve from PyPI — `bashrun` (shell-outs), `packaging` (`requires` specifier parsing), `pathspec`, `pydantic`/`pydantic-settings`, `pyyaml` (score-document parsing), `strictyaml` (config loading), `typer` (CLIs) — git-source pins only in scratch branches testing unreleased changes. The repo and package renamed twice on the way here — `stack-lifecycle` → `stack-toolkit` (2026-09-20, before any publish) and `stack-toolkit` → `docker-devkit` (2026-09-21, member of the `-devkit` family). The PyPI identity is fresh: `docker-devkit` starts its own tag ledger at `0.1.0`; the terminal `stack-toolkit` distributions (≤0.1.1) are deprecation signposts pointing here, not this package's history.
 
-Config surfaces org-wide follow one law (its home is release-devkit's `AGENTS.md`): config lives beside the unit whose facts it carries; consumption model and config location are independent axes. Every devkit configures via one root `<devkit>.yaml` per repo — except python-devkit (pyproject `[tool.python-devkit.*]` tables, its subject being the Python workspace) and unity-devkit (JSON, read by C# inside Unity, which ships no YAML parser). A docker-devkit consumer declares a root `docker-devkit.yaml` whose schema (`config.DockerDevkitConfig`, strictyaml-loaded, `extra="forbid"` on every model) carries a required `requires` version stamp plus optional `lifecycle` / `mirror` / `generate-score` sections; `config.load_config` self-checks the installed docker-devkit version against `requires` and refuses loudly outside the range (the `0.0.0.dev0` dev sentinel bypasses the check, not the field). Strictyaml preserves all scalars as strings (no implicit typing) and rejects duplicate keys and flow-style collections, so empty collections are expressed by omitting the key, not by `[]`/`{}`. This repo itself is published by root `release-devkit.json`.
+Config surfaces org-wide follow one law (its home is release-devkit's `AGENTS.md`): config lives beside the unit whose facts it carries; consumption model and config location are independent axes. Every devkit configures via one root `<devkit>.yaml` per repo — except python-devkit (pyproject `[tool.python-devkit.*]` tables, its subject being the Python workspace) and unity-devkit (JSON, read by C# inside Unity, which ships no YAML parser). A docker-devkit consumer declares a root `docker-devkit.yaml` whose schema (`config.DockerDevkitConfig`, strictyaml-loaded, `extra="forbid"` on every model) carries a required `requires` version stamp plus optional `lifecycle` / `mirror` / `generate-score` sections; `config.load_config` self-checks the installed docker-devkit version against `requires` and refuses loudly outside the range (the `0.0.0.dev0` dev sentinel bypasses the check, not the field). Strictyaml preserves all scalars as strings (no implicit typing) and rejects duplicate keys and flow-style collections, so empty collections are expressed by omitting the key, not by `[]`/`{}`. This repo itself is published by root `release-devkit.yaml`.
 
 ## Release flow
 
-Publishing rides `release.yml`, triggered by a successful CI run on a `main` push: the machinery — release-devkit's `publish-stable` (an inlined, version-pinned `uvx` step in the publish job, keeping OIDC identity local), never a project dependency (docker-devkit sits inside its own dependency graph; a project-level release-devkit edge is a resolver cycle) — computes the plan from the tag ledger and path-diff, patches the version ephemerally, and publishes to PyPI under OIDC trusted publishing (publisher bound to `release.yml`, no environment). The committed `pyproject.toml` version is permanently the `0.0.0.dev0` sentinel; the `docker-devkit-v*` tags are the version ledger (declared `major_minor` line in `release-devkit.json`, patch-auto within the line). While pre-1.0, breaking changes ride the normal patch flow without a bump; from 1.0 on, API-breaking changes ship with a manually bumped `major_minor` — patch-auto assumes additive changes.
+Publishing rides `release.yml`, triggered by a successful CI run on a `main` push: the machinery — release-devkit's `publish-stable` (an inlined, version-pinned `uvx` step in the publish job, keeping OIDC identity local), never a project dependency (docker-devkit sits inside its own dependency graph; a project-level release-devkit edge is a resolver cycle) — computes the plan from the tag ledger and path-diff, patches the version ephemerally, and publishes to PyPI under OIDC trusted publishing (publisher bound to `release.yml`, no environment). The committed `pyproject.toml` version is permanently the `0.0.0.dev0` sentinel; the `docker-devkit-v*` tags are the version ledger (declared `major_minor` line in `release-devkit.yaml`, patch-auto within the line). While pre-1.0, breaking changes ride the normal patch flow without a bump; from 1.0 on, API-breaking changes ship with a manually bumped `major_minor` — patch-auto assumes additive changes.
 
 ## Shape
 

{docker_devkit-0.1.20 → docker_devkit-0.1.22}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: docker-devkit
-Version: 0.1.20
+Version: 0.1.22
 Summary: Docker-stack lifecycle commands (up/down/build) driven by a pyproject-declared compose assembly
 License-File: LICENSE
 License-File: NOTICE

{docker_devkit-0.1.20 → docker_devkit-0.1.22}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "docker-devkit"
-version = "0.1.20"
+version = "0.1.22"
 description = "Docker-stack lifecycle commands (up/down/build) driven by a pyproject-declared compose assembly"
 requires-python = ">=3.13"
 dependencies = [

docker_devkit-0.1.22/release-devkit.yaml

@@ -0,0 +1,8 @@
+requires: ">=0.1"
+ci_workflow: ci.yml
+packages:
+  docker-devkit:
+    path: .
+    major_minor: "0.1"
+    registries:
+      pypi: docker-devkit

docker_devkit-0.1.20/release-devkit.json

@@ -1,10 +0,0 @@
-{
-  "packages": {
-    "docker-devkit": {
-      "path": ".",
-      "major_minor": "0.1",
-      "registries": { "pypi": "docker-devkit" }
-    }
-  },
-  "ci_workflow": "ci.yml"
-}