dactopus 0.2.0__tar.gz

dactopus-0.2.0/.github/dependabot.yml

@@ -0,0 +1,10 @@
+version: 2
+updates:
+  - package-ecosystem: uv
+    directory: /
+    schedule:
+      interval: monthly
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: monthly

dactopus-0.2.0/.github/workflows/ci.yml

@@ -0,0 +1,37 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python: ["3.11", "3.12", "3.13"]
+    env:
+      UV_PYTHON: ${{ matrix.python }}
+    steps:
+      - uses: actions/checkout@v7
+      - uses: astral-sh/setup-uv@v7
+      - run: uv sync --locked
+      - run: uv run ruff check src tests
+      - run: uv run ruff format --check src tests
+      - run: uv run pytest -q -m "not integration"
+
+  package:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: astral-sh/setup-uv@v7
+      - run: uv build
+      - run: uvx twine check --strict dist/*  # the README is the PyPI page
+      - name: The wheel works on its own, outside the checkout
+        run: |
+          uv venv "$RUNNER_TEMP/wheel"
+          uv pip install --python "$RUNNER_TEMP/wheel" "$(ls dist/*.whl)"
+          cd "$RUNNER_TEMP" && wheel/bin/dactopus init --config sample.yaml
+          wheel/bin/python -c "import dactopus.serve, dactopus_ossie_clickhouse.mcp_server"

dactopus-0.2.0/.github/workflows/publish.yml

@@ -0,0 +1,72 @@
+name: Publish
+
+# A release on GitHub publishes its tag to PyPI. Run by hand, the same build goes to
+# TestPyPI under a dev version (X.Y.Z.devN, N the run number, since an index takes
+# each version once): a rehearsal on main before the tag. Both indexes trust this
+# workflow and its environment (trusted publishing), so no token is stored here.
+on:
+  release:
+    types: [published]
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          fetch-depth: 0  # the history of main, for the ancestry check below
+      - uses: astral-sh/setup-uv@v7
+      - name: The tag is the version in pyproject.toml
+        if: github.event_name == 'release'
+        run: test "$GITHUB_REF_NAME" = "v$(uv version --short)"
+      - name: The tagged commit is on main
+        if: github.event_name == 'release'
+        run: |
+          git merge-base --is-ancestor HEAD origin/main || {
+            echo "::error::$GITHUB_REF_NAME is not on main: tag the commit main got from the merge"
+            exit 1
+          }
+      - name: A dev version for TestPyPI
+        if: github.event_name == 'workflow_dispatch'
+        run: uv version --frozen "$(uv version --short).dev$GITHUB_RUN_NUMBER"
+      - run: uv build
+      - run: uvx twine check --strict dist/*
+      - uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  pypi:
+    if: github.event_name == 'release'
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/dactopus/
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - uses: pypa/gh-action-pypi-publish@release/v1
+
+  testpypi:
+    if: github.event_name == 'workflow_dispatch'
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: testpypi
+      url: https://test.pypi.org/project/dactopus/
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          repository-url: https://test.pypi.org/legacy/

dactopus-0.2.0/.gitignore

@@ -0,0 +1,14 @@
+CLAUDE.local.md
+.claude/
+.DS_Store
+.knowledge_private/
+.venv/
+__pycache__/
+.pytest_cache/
+.ruff_cache/
+dist/
+.coverage
+
+# Local installations and their output
+/dactopus.yaml
+.dactopus/

dactopus-0.2.0/AGENTS.md

@@ -0,0 +1,218 @@
+# AGENTS.md
+
+Guidance for AI coding agents working in this repository. What the product
+is and why: [README.md](README.md).
+
+## Project
+
+dactopus is the runner of Dactopus: the process a client installs next to
+their ClickHouse. It loads sources into that ClickHouse, runs the source
+packages of [dactopus-data-models](https://github.com/Dactopus/dactopus-data-models)
+(dbt projects) to build the canonical tables, runs checks, and serves the
+Ossie models of those tables to AI agents over MCP through
+[dactopus-ossie-clickhouse](https://github.com/Dactopus/dactopus-ossie-clickhouse).
+The command line is the whole runner: no control plane, no scheduler.
+
+The word is *runner*. Never call it an agent: an agent is the AI that
+talks to the MCP server.
+
+Licensed under Apache 2.0.
+
+## Language
+
+All text in this repository is in English only: code identifiers, comments,
+docstrings, commit messages, documentation, issues, and test names. Do not
+introduce text in any other language, even in examples or fixtures.
+
+## Scope
+
+In scope:
+
+- One configuration file per installation: the ClickHouse connection and
+  the user `serve` connects as, the databases for raw input and canonical
+  tables, the store's time zone, the version of the models
+  library, the packages to run and their parameters.
+- Loading GA4: the BigQuery export, read with the Storage Read API, into
+  the GA4 package's input table.
+- Loading Shopify: orders with lines, shipping and refunds, and the
+  products with their deletions, read page by page from the GraphQL
+  Admin API, into the Shopify package's input tables.
+- Running the packages with dbt.
+- Checks behind a plugin interface, built-in checks, and one report a
+  store owner can read.
+- Serving the models over MCP, as a thin call to dactopus-ossie-clickhouse.
+
+Out of scope, do not build:
+
+- Transport for other sources. A database (WooCommerce on MySQL) reaches
+  ClickHouse by CDC (PeerDB, ClickPipes) the client sets up; the runner
+  reads the tables it finds. No replication engine, no wrapper over
+  PeerDB, Debezium or dlt.
+- Transformations and model descriptions. SQL that maps a source to an
+  entity belongs in a package of dactopus-data-models; a description
+  belongs in its Ossie model. The runner ships neither.
+- Query execution and MCP tools. That is dactopus-ossie-clickhouse.
+- Scheduling, alerts, run history, a control plane, a user interface.
+  Runs are started by hand or by the client's cron.
+- Merging model files or overlaying fragments on them. The executor
+  reads several files as one model; the runner only lists them.
+- Migration from a client's dbt or Looker.
+- An installer, a Docker image, a single-file build. Installation is
+  `uv`, as for the executor.
+- Placeholders or stubs for any of the above.
+
+## Design principles
+
+- Thin. Every command is the Quick start of dactopus-data-models made
+  portable: the same steps, one tool, one configuration file. A new
+  concept needs a decision first.
+- The library owns the input contract (`sources/<source>/input.sql`:
+  the tables a package reads) and the transformations; the runner owns
+  delivery to that contract and running. A gap between the two is fixed
+  in the library, never patched around in the runner.
+- The runner knows a package only by its `input.sql` and its
+  `sources/<package>/deployment.yml`: the Ossie model its tables serve,
+  the dbt variables that take the input database and the time zone, and
+  the tables counted per day. A variable, table, column or model file
+  name of a package never appears in the runner's code. Two exceptions:
+  the loaders, which write the tables `input.sql` defines (the GA4
+  loader also rereads as many days as the package's
+  `ga4_lookback_days`), and the commented sample `init` writes.
+- The executor knows nothing of Dactopus; the runner is a consumer like
+  any other. What the runner needs from it is proposed there as a
+  feature for every Ossie user.
+- Data and secrets stay with the client. The runner writes only to the
+  client's ClickHouse. Credentials come from environment variables or
+  files the configuration names, and never appear in logs, reports or
+  error messages.
+- No database name is written into a model or a package; the
+  configuration chooses them, the runner passes them to dbt as variables
+  and to `input.sql` as a query parameter.
+- A run over unchanged input changes nothing, and a second load of the
+  same rows is harmless.
+- One plugin interface: checks. Everything else is a direct call.
+- Keep the public surface small: four commands, one configuration file.
+
+## Stack
+
+Python 3.11+, managed with uv. The parts that constrain code:
+
+- **dbt v1**: `dbt-core` 1.11 with `dbt-clickhouse`. Packages are dbt
+  projects and also run on dbt v2, but its ClickHouse adapter is in beta
+  (reads LZ4 only, `source freshness` broken), so the runner pins v1
+  until the adapter is generally available.
+- **dactopus-ossie-clickhouse** for `serve` and for validating the
+  models against the built tables.
+- **clickhouse-connect** with the `arrow` extra for loading: Arrow
+  tables go in with `insert_arrow`, which maps Arrow structs to `Tuple`
+  columns by field name and drops struct fields the table lacks.
+- **google-cloud-bigquery-storage** for GA4: the Storage Read API returns
+  Arrow, selects columns and filters rows, and reads tables only, not
+  views. The daily tables are listed with one BigQuery REST call
+  (`tables.list`) through `google-auth`, which comes with it; no
+  `google-cloud-bigquery`.
+- The Shopify client is the standard library (`urllib`) with `certifi`
+  for root certificates, as in the library's README recipe. No dlt: its Shopify source uses the legacy
+  REST Admin API.
+- No ClickHouse binaries on the runner's machine: `clickhouse local` and
+  `clickhouse client` in the library's recipes are replaced by Python.
+- **tzdata** on every platform: the names of time zones do not depend
+  on the age of the machine's tz database.
+
+The models library is not a Python package. The configuration names a
+version (`models.version`: a release tag, fetched as the GitHub archive
+of the tag into `~/.cache/dactopus/`, no git needed) or a path
+(`models.path`, for development). Packages run one at a time with
+`dbt build --project-dir <library>/sources/<package>`, with a profile
+the runner writes; the package names it (`profile: dactopus`). Packages
+do not depend on each other; no root dbt project is generated.
+
+## Architecture rules
+
+- Layering: configuration -> loaders (one per source) -> build (dbt) ->
+  checks -> report. `serve` is a call to the executor with a list of
+  files. Lower layers never import higher ones.
+- Commands: `dactopus run` (load, build, check, report), `dactopus check`
+  (checks and report only), `dactopus serve` (MCP), `dactopus init`
+  (writes a commented sample configuration; no dialogue). Separate load
+  and build commands appear when someone needs them apart; until then
+  they are flags of `run`.
+- A loader creates the package's input tables by running the package's
+  `input.sql` from the library, never from a copy, and writes nothing
+  else. GA4: select the top-level columns of the Arrow table and insert
+  it as is, no struct projection, no Parquet on disk; incremental loads
+  reread the daily tables from `max(event_date)` in the input minus the
+  package's `ga4_lookback_days` (default 3) and replace those days.
+  Shopify: pages of 25 orders with lines, shipping and refunds, then
+  pages of 100 products and the deletions of products from the store's
+  events; an incremental load filters `updated_at:>=` from the latest
+  loaded change of its kind minus one hour and appends the versions it
+  gets (the package keeps every version and dedupes). Bulk operations do
+  not deliver refund lines; do not use them for the full load.
+- A check is a named object that takes a ClickHouse connection and the
+  installation's configuration and returns findings. A finding has one
+  shape for built-in and plugin checks alike: check, object, severity,
+  observed, expected, and a sentence for the owner. Checks register
+  through Python entry points; built-in ones are dbt test results (from
+  `target/run_results.json` with `manifest.json` for the test's kind,
+  column and parameters), input freshness, rows per day, and the time
+  zone of the daily tables against `store.timezone`. The report
+  is Markdown, to the terminal and to a file, three answers first (how
+  fresh the data is; whether every check passed and which did not, in
+  words; volumes per day this week against past weeks), details below.
+  The exit code is non-zero on a `fail` or `error` finding.
+- `serve` passes the model file each configured package declares and
+  the connection; the executor combines them. The runner does not read,
+  merge or edit model files.
+- Memory: a daily GA4 table of a mid-size brand is hundreds of megabytes
+  of Arrow. Keep it; read in `ReadRows` batches when a load exceeds it.
+- Errors name the step, the object and the next action in plain words;
+  the owner reads the report, the engineer reads the log.
+
+## Testing
+
+- A loader is accepted when the input it writes equals, row for row,
+  what the library's README recipe writes from the same source: the
+  public GA4 sample `ga4_obfuscated_sample_ecommerce`, the Shopify rows
+  in the library's `tests/shopify/fixture.sql` and a development store.
+- Build and checks are accepted when the package's own `dbt build` and
+  the library's `tests/<source>/check_numbers.py` pass over tables the
+  runner loaded.
+- Tests that use the `clickhouse` fixture are integration tests: they
+  need a server at `DACTOPUS_CLICKHOUSE_URL` (user, host and port, as
+  `clickhouse.url`; default `http://127.0.0.1:8123`), with the password
+  in `CLICKHOUSE_PASSWORD`, and skip otherwise. Tests that need BigQuery
+  or Shopify credentials skip without them; loader logic is tested on
+  recorded Arrow and JSON fixtures.
+- Every change to library code comes with a test. Facts about the
+  BigQuery export, the Shopify API and ClickHouse behaviour come from
+  running them, not from memory; a version and a date go with each fact
+  written down.
+
+## Development
+
+Layout: `src/dactopus/` (library and CLI), `tests/` (pytest, fixtures in
+`tests/fixtures/`), `docs/`. Keep modules flat; add a package level only
+when a module outgrows one file.
+
+```bash
+uv sync                               # install with dev tools
+uv run pytest                         # tests; ClickHouse-dependent ones skip when no server
+uv run pytest -m "not integration"    # unit tests only
+uv run ruff check src tests           # lint
+uv run ruff format src tests          # format
+uv run dactopus init                  # write dactopus.yaml with comments
+uv run dactopus run --config dactopus.yaml
+uv run dactopus check --config dactopus.yaml
+uv run dactopus serve --config dactopus.yaml   # MCP over stdio
+```
+
+Issues and pull requests in this repository are opened by the
+maintainer, not by an agent on its own.
+
+## Repository status
+
+A prototype; 0.1.0 is the first release. Versions follow
+Semantic Versioning, the changelog follows Keep a Changelog, a release is
+the tag `vX.Y.Z` with the GitHub release titled `X.Y.Z`. Pull requests
+are merged with rebase.

dactopus-0.2.0/CHANGELOG.md

@@ -0,0 +1,139 @@
+# Changelog
+
+All notable changes to this project are recorded here. The format follows
+[Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow
+[Semantic Versioning](https://semver.org/). While the major version is 0,
+a minor release may change the command line and the configuration file.
+
+## [Unreleased]
+
+## [0.2.0] - 2026-11-01
+
+### Added
+
+- On PyPI: `uv tool install dactopus`. A release on GitHub publishes its
+  tag (`.github/workflows/publish.yml`, trusted publishing); run by hand,
+  the workflow uploads a dev version to TestPyPI as a rehearsal. CI builds
+  the package, checks that its README renders as the PyPI page, and runs
+  the wheel outside the checkout. The README's links are absolute, so
+  they work on PyPI.
+
+### Changed
+
+- dactopus-ossie-clickhouse 0.13.0, from PyPI in place of a git
+  reference to 0.12.0. It carries its own copy of apache-ossie, so
+  apache-ossie is no longer installed with the runner. `dactopus serve`
+  gains the questions the executor answers since 0.12.1
+  ([its changelog](https://github.com/Dactopus/dactopus-ossie-clickhouse/blob/main/CHANGELOG.md)).
+
+## [0.1.1] - 2026-10-30
+
+### Added
+
+- `docs/design.md`: the decisions behind the runner, the reasons for
+  each and what each was verified on. The README gains the scope of
+  0.1.0: what the runner does not do and what it is untested on.
+
+## [0.1.0] - 2026-10-30
+
+The first release, a prototype.
+
+### Added
+
+- The `dactopus` command with `init`, `run`, `check` and `serve`,
+  installed with `uv tool install` from a release tag on GitHub.
+- The configuration file `dactopus.yaml`: the ClickHouse connection, over
+  TLS for an `https://` URL (port 8443 by default), with the password from
+  an environment variable, the databases for input and
+  canonical tables, the store's time zone (`store.timezone`, required),
+  the models library by release or by path, and the GA4 and Shopify
+  packages with their dbt variables.
+- `dactopus init` writes a commented sample configuration.
+- A release of the models library is downloaded once from GitHub into
+  `~/.cache/dactopus/`.
+- `dactopus run` loads GA4 and Shopify and builds their packages. GA4: the
+  daily tables of the BigQuery export through the Storage Read API, the
+  last `ga4_lookback_days` reread and replaced on every run, as the
+  Google account the load names; a gcloud login bills the reads to the
+  configured project. Shopify: orders with lines, shipping and refunds,
+  then the products, archived ones and drafts included, and the
+  deletions of products from the store's events, from the GraphQL Admin
+  API (2026-10), each kind from an hour before its latest loaded change,
+  with a token from the app's client credentials (`read_orders` and
+  `read_products`); a models library before v0.7.0, whose Shopify input
+  has no `products`, is refused before anything is loaded, with the
+  version to set. A refund carries its `processedAt`, the date Shopify's
+  reports count it on and the models library's since v0.7.2; a library
+  before it, or a refunds table an earlier library created, is refused
+  the same way, naming the library's changelog for adding the column.
+  Each package is built with
+  `dbt build` and a dbt profile the runner writes, not the one in the
+  package; the profile and dbt's output go to `.dactopus/` next to the
+  configuration.
+- Checks and the report. A check is a function of a ClickHouse client and
+  the configuration that returns findings of one shape (check, object,
+  severity, observed, expected, a sentence for the owner), registered
+  through the entry point group `dactopus.checks`. Built in: the models,
+  tests and unit tests of the last dbt run, the freshness of the input
+  against the package's thresholds (`dbt source freshness`), and a day
+  without rows in the last seven days that are over of a table the
+  package marks as a gap (`events`, `orders`), unless the same weekday
+  had none in the four weeks before.
+  `dactopus run` ends with the report, `dactopus check` runs `dbt test`
+  and the checks without loading or building; both write it to the
+  terminal and to `.dactopus/report.md` (freshness, what did not pass,
+  rows per day for the last seven days that are over, in
+  `store.timezone` for Shopify, against the four weeks before, then every
+  finding) and exit with 1 on a `fail` or `error` or when no check ran. An unknown
+  `store.timezone`, and `shopify_timezone` among the package's vars, are
+  refused before any connection. A dbt run
+  with failing tests or models no longer stops the command: its results
+  are in the report.
+- `dactopus run --full-refresh [PACKAGE ...]` rebuilds the canonical
+  tables of the named packages (every configured package when none is
+  named) from the input the runner holds, with `dbt build --full-refresh`
+  after the usual load; the input is not reloaded. For a release of the
+  models library that changes a model's columns, which the `dbt` check
+  reports together with this command, or a change of the store's time
+  zone.
+- `dactopus serve` runs the MCP server of dactopus-ossie-clickhouse 0.12.0
+  over stdio with the models of the configured packages
+  (`entities/web_analytics.yaml` for GA4, `entities/commerce.yaml` for
+  Shopify) read as one model, on the canonical database, over TLS for an
+  `https://` URL on any port, as the ClickHouse user of the optional
+  `serve` section (`user`, `password_env`) or else the user of
+  `clickhouse.url`, with "today" in `store.timezone` (the executor's
+  `--time-zone`). Each command reads only the password it connects
+  with. The password reaches the executor inside the process, never on a
+  command line.
+- One time zone per installation, `store.timezone`: the runner passes it
+  to every package that declares a time zone variable and to `serve`.
+  With Shopify configured, `dactopus run` reads the shop's zone
+  (`shop { ianaTimezone }`) before loading and refuses a different
+  `store.timezone`, naming both; another name of the same zone (`UTC`
+  for `Etc/UTC`) passes. Before loading it also counts the rows of
+  the daily tables of each package with a time zone variable whose date
+  is not the day of their time in `store.timezone`, and stops on any with
+  the `dactopus run --full-refresh <package>` that rebuilds them; a
+  package rebuilt with `--full-refresh` is not counted. The built-in check
+  `time_zone` runs the same count after the build: a `fail` for a package
+  with a time zone variable, a `warn` with the share of rows for one
+  without (GA4, whose days are the property's), over the days
+  `rows_per_day` reads. Zone names come from the `tzdata` package on
+  every platform as well, so a name newer than the machine's own tz
+  database (`Europe/Kyiv`) is known.
+- The runner reads what it sets and reads of a package from the
+  package's `deployment.yml` in the models library: the Ossie model
+  `serve` passes, the dbt variables that take the input database and the
+  time zone, and the tables `rows_per_day` counts, with the ones where a
+  day without rows is a finding. A renamed variable, model file or
+  counted table needs no release of the runner. The models library must be
+  v0.6.0 or later, the first release with the file; the sample
+  configuration names v0.8.0, and an older `models.version` is refused
+  with the version to set. The vars of a package are checked against
+  the file before any connection.
+
+[Unreleased]: https://github.com/Dactopus/dactopus/compare/v0.2.0...HEAD
+[0.2.0]: https://github.com/Dactopus/dactopus/releases/tag/v0.2.0
+[0.1.1]: https://github.com/Dactopus/dactopus/releases/tag/v0.1.1
+[0.1.0]: https://github.com/Dactopus/dactopus/releases/tag/v0.1.0

dactopus-0.2.0/CLAUDE.md

@@ -0,0 +1 @@
+@AGENTS.md

dactopus-0.2.0/CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# Contributing
+
+Bug reports and questions are welcome as issues. Everything in this
+repository is in English: code, comments, commit messages, issues.
+
+## Setup
+
+Python 3.11+ and [uv](https://docs.astral.sh/uv/).
+
+```bash
+git clone https://github.com/Dactopus/dactopus
+cd dactopus
+uv sync
+uv run pytest -m "not integration"     # unit tests, no server needed
+```
+
+Integration tests need a ClickHouse server reachable over HTTP at
+`DACTOPUS_CLICKHOUSE_URL` (user, host and port, without the password;
+default `http://127.0.0.1:8123`), with the password in
+`CLICKHOUSE_PASSWORD`, and skip without one.
+
+```bash
+uv run ruff check src tests
+uv run ruff format src tests
+```
+
+## Rules that shape the code
+
+[AGENTS.md](AGENTS.md) is the full list. The scope section says what the
+runner does and what it leaves to the library, the executor and the
+client's own tools; read it before proposing a feature.
+
+## Pull requests
+
+Small and focused. CI runs lint, the format check and the tests. By
+submitting a contribution you agree it is licensed under the Apache
+License 2.0, like the rest of the project.
+
+## Releasing
+
+For maintainers. A release is the tag `vX.Y.Z` on a commit on `main`; the
+GitHub release is titled `X.Y.Z`.
+
+1. Move the `[Unreleased]` entries in `CHANGELOG.md` under
+   `## [X.Y.Z] - YYYY-MM-DD`, leaving `[Unreleased]` empty.
+2. Set `version` in `pyproject.toml` and run `uv lock`.
+3. Push, wait for CI, merge with "Rebase and merge".
+4. Rehearse on `main`: run the Publish workflow by hand. It uploads the
+   build to [TestPyPI](https://test.pypi.org/project/dactopus/) as
+   `X.Y.Z.devN`; install that from there, its dependencies from PyPI
+   (anyone may upload to TestPyPI, under any name), and look at the page.
+   PyPI takes each version once, so whatever goes wrong is fixed here,
+   before the tag.
+5. Tag the commit on `main`, never one on the branch: rebasing changes the
+   hashes. Publishing the release on GitHub runs the Publish workflow,
+   which checks that the tag is the version in `pyproject.toml` and its
+   commit is on `main`, then uploads to PyPI. The release notes are the changelog section plus the
+   install line pinned to the version.
+
+```bash
+git switch main && git pull --ff-only
+gh workflow run publish.yml --ref main   # step 4, TestPyPI
+uvx pip download --no-deps --index-url https://test.pypi.org/simple/ -d testpypi "dactopus==X.Y.Z.devN"
+uv tool install --force testpypi/dactopus-X.Y.Z.devN-py3-none-any.whl   # dependencies from PyPI
+git tag -a vX.Y.Z -m "dactopus X.Y.Z" && git push origin vX.Y.Z
+gh release create vX.Y.Z --title X.Y.Z --notes-file notes.md   # publishes to PyPI
+```