plausible2umami 0.1.0__tar.gz

plausible2umami-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,25 @@
+name: publish
+
+# Trusted publishing: PyPI verifies this workflow's identity through OIDC, so
+# there is no API token to store or rotate. The matching publisher has to be
+# configured on PyPI for owner einsz, repo plausible2umami, workflow
+# publish.yml, with the environment field left blank.
+
+on:
+  release:
+    types: [published]
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.13"
+      - run: pip install build
+      - run: python -m build
+      - run: pip install twine && twine check dist/*
+      - uses: pypa/gh-action-pypi-publish@release/v1

plausible2umami-0.1.0/.github/workflows/test.yml

@@ -0,0 +1,20 @@
+name: tests
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  pytest:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python: ["3.10", "3.13"]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python }}
+      - run: pip install -e '.[dev]'
+      - run: pytest -q

plausible2umami-0.1.0/.gitignore

@@ -0,0 +1,8 @@
+__pycache__/
+*.py[cod]
+.venv/
+dist/
+build/
+*.egg-info/
+.pytest_cache/
+*.jsonl

plausible2umami-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 einsz
+
+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.

plausible2umami-0.1.0/PKG-INFO

@@ -0,0 +1,276 @@
+Metadata-Version: 2.5
+Name: plausible2umami
+Version: 0.1.0
+Summary: Migrate self-hosted Plausible analytics into Umami v3, event by event
+Project-URL: Homepage, https://github.com/einsz/plausible2umami
+Project-URL: Issues, https://github.com/einsz/plausible2umami/issues
+Author: einsz
+License-Expression: MIT
+License-File: LICENSE
+Keywords: analytics,clickhouse,migration,plausible,umami
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: System Administrators
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Internet :: Log Analysis
+Requires-Python: >=3.10
+Provides-Extra: all
+Requires-Dist: clickhouse-connect>=0.7; extra == 'all'
+Requires-Dist: psycopg[binary]>=3.1; extra == 'all'
+Provides-Extra: dev
+Requires-Dist: pytest>=8; extra == 'dev'
+Provides-Extra: extract
+Requires-Dist: clickhouse-connect>=0.7; extra == 'extract'
+Provides-Extra: load
+Requires-Dist: psycopg[binary]>=3.1; extra == 'load'
+Description-Content-Type: text/markdown
+
+# plausible2umami
+
+Migrate **self-hosted** Plausible analytics into Umami v3, one event at a time.
+
+Most Plausible-to-Umami tools read Plausible's CSV export. That export is daily
+totals per dimension, not events, so those tools have to invent the sessions
+that Umami needs: attributes drawn independently from daily distributions,
+pageviews spread round-robin across synthetic visits. The daily chart ends up
+about right and every individual row is fiction.
+
+If you self-host Plausible you don't have to accept that. Your raw events are
+sitting in ClickHouse with real timestamps, real session ids, referrers and
+device data, one row per event. This tool reads those.
+
+## What it needs
+
+- Plausible Community Edition, self-hosted, with access to its ClickHouse
+  (the `events_v2` table)
+- Umami **v3.x on PostgreSQL**. v3 dropped MySQL and MariaDB, and this tool
+  targets v3 only. The v3 images live on Docker Hub as
+  `umamisoftware/umami:3.3.1` rather than ghcr, and the `postgresql-` tag
+  prefix is gone now that Postgres is the only option
+
+## Use
+
+Create the target website in Umami's UI first, then copy its id out of the
+tracking snippet.
+
+Find the Plausible site id and see how much data there is:
+
+```sh
+docker compose exec plausible_events_db clickhouse-client \
+  -q "SELECT site_id, count() AS events, min(timestamp), max(timestamp)
+      FROM plausible_events_db.events_v2 GROUP BY site_id"
+```
+
+Extract, inspect, load:
+
+```sh
+pip install 'plausible2umami[all] @ git+https://github.com/einsz/plausible2umami'
+
+plausible2umami extract --site-id 1 --out events.jsonl
+plausible2umami load --in events.jsonl --website-id <uuid> --dry-run
+plausible2umami load --in events.jsonl --website-id <uuid> \
+    --dsn postgres://umami:pass@localhost:5432/umami
+```
+
+If ClickHouse isn't reachable from where you're running this, which is common,
+skip `extract` and produce the same file from inside the container:
+
+```sh
+plausible2umami query --site-id 1        # prints the SQL
+
+docker exec <clickhouse-container> clickhouse-client \
+  -q "<that SQL> FORMAT JSONEachRow" | gzip > events.jsonl.gz
+```
+
+The output format is identical either way, and `load` reads `.gz` directly.
+Keep the query's `ORDER BY` if you write it out by hand: it groups each
+visitor's events together and puts identical events next to each other, which
+is what lets the loader stream a multi-gigabyte file in flat memory.
+
+### Large sites: extract one day at a time
+
+Do not run the single-query extract against a site with millions of events on a
+small server. The `ORDER BY` makes ClickHouse sort the whole result, and
+Plausible's own `low-resources.xml` caps threads while leaving sort memory
+unbounded, with `max_bytes_before_external_sort` at its default of 0, meaning
+it never spills to disk. On a 4 GB host with Plausible already resident, a
+13.5 million row sort takes the machine into swap.
+
+```sh
+plausible2umami query --site-id 1 --by-day --out /tmp/site1 > extract.sh
+sh extract.sh
+```
+
+That fetches a day per query, so no sort exceeds one day's rows, and it reads
+only the relevant parts because `site_id` and the date lead the table's primary
+key. One file per day means an interrupted run resumes rather than restarting,
+and the parts are concatenated at the end without recompression, since joined
+gzip members are valid gzip.
+
+This is safe because Plausible's `user_id` is a hash whose salt rotates daily,
+so every row for a given visitor falls inside one day. Chunking by day
+preserves exactly the grouping the loader depends on.
+
+### Scale, and what it costs in disk
+
+Both phases stream, so memory stays flat regardless of size. Disk does not.
+
+Measured on a real migration of 9,753,130 events spanning two and a half years,
+loaded into a fresh Umami v3.3.1:
+
+| | |
+|---|---|
+| Extract, gzipped JSONL | 127 MB |
+| Load time | 33 minutes |
+| Postgres afterwards | **9,179 MB** |
+| of which row data | 1,258 MB |
+| of which indexes | **7,539 MB** |
+| The same events in ClickHouse | **127 MiB** |
+
+Umami puts fifteen indexes on `website_event`, and they cost six times the data
+they index. Your events are the cheap part.
+
+Four of them index columns Plausible has no equivalent for, so they sit empty
+after an import: `page_title`, `tag`, `url_query`, and `event_name` unless you
+keep engagement events. Roughly 2 GB of index over nothing.
+
+Decide how much history you want before you start. `--since` filters at load
+time from an extract you already have, so changing your mind costs a flag
+rather than another trip to ClickHouse.
+
+## What actually maps
+
+The identity mapping is the part worth understanding, and it is easy to get
+backwards:
+
+| Plausible | Umami | Meaning |
+|---|---|---|
+| `user_id` | `session.session_id` | the visitor |
+| `session_id` | `website_event.visit_id` | the 30-minute visit |
+
+Plausible's `user_id` is a salted hash that rotates daily, so an imported Umami
+session is really a visitor-day. That is a property of Plausible's data model,
+not something this tool discards.
+
+### Copied directly
+
+| Plausible `events_v2` | Umami |
+|---|---|
+| `timestamp` | `created_at` |
+| `name` | `event_type` (1 pageview, 2 custom) and `event_name` |
+| `pathname` | `url_path`, `url_query` |
+| `hostname` | `hostname` |
+| `referrer` | `referrer_domain`, `referrer_path`, `referrer_query` |
+| `utm_source` `utm_medium` `utm_campaign` `utm_content` `utm_term` | same names |
+| `browser` | `session.browser` |
+| `operating_system` | `session.os` |
+| `screen_size` | `session.device` |
+| `country_code` | `session.country` |
+| `subdivision1_code` | `session.region` |
+| `city_name` | `session.city` |
+
+Plausible's `screen_size` is a bucket ("Desktop", "Mobile"), which is Umami's
+`device`. Umami's `screen` wants "1920x1080" and has no source here.
+
+### Left null, because Plausible never collected it
+
+`session.language`, `session.screen`, `session.distinct_id`, `page_title`, and
+the web-vitals columns (`lcp`, `inp`, `cls`, `fcp`, `ttfb`).
+
+City is mapped. The extract selects `city_name`, an ALIAS column that resolves `city_geoname_id` against Plausible's bundled
+`location_data_dict`, so no GeoNames table has to be shipped.
+
+Whether you get anything depends on your GeoIP database. Plausible only records
+`city_geoname_id` when it has a **city-level** one; with country-level data the
+id is 0 for every event and `session.city` ends up null.
+On the instance this was developed against, all 5,102 test events had id 0, so
+the mapping is verified only as far as the dictionary: `dictGet` resolves ids
+to names correctly ("Berlin", "New York City"), but no live event
+carrying a real id was ever migrated.
+
+If your Plausible predates the `city_name` alias, remove it from the extract
+query. The loader treats a missing `city_name` as null rather than failing.
+
+### Dropped, no Umami equivalent
+
+`scroll_depth`, `engagement_time`, the `revenue_*` fields, `click_id_param`,
+`acquisition_channel`, and `browser_version` / `operating_system_version`.
+
+### Filtered out by default
+
+Plausible emits an internal `engagement` event alongside pageviews, carrying
+`scroll_depth` and `engagement_time`. Umami has nowhere to put either, so
+importing them adds rows and no information while filling Umami's custom-events
+list with a single meaningless name.
+
+They are dropped unless you pass `--include-engagement`. The volume is worth
+knowing: on the site this was first tested against, 3,557 of 5,094 events were
+engagement. Filtering them left pageviews, visitors and visits identical and
+cut the row count by 70%.
+
+### Not implemented
+
+- **Custom event properties.** `meta.key` / `meta.value` would map to Umami's
+  `event_data` table. Custom event *names* are imported; their properties are
+  not.
+
+Nothing is fabricated. Every field outside the tables above lands as null.
+
+## Safety
+
+Re-running is safe. Every id is a UUIDv5 derived from the source data and the
+target website id, and every insert is `ON CONFLICT DO NOTHING`, so a load that
+dies partway through can just be run again. Rows already written are left
+alone.
+
+- `--dry-run` transforms everything and writes nothing, printing counts, the
+  date range and a sample of what would go in
+- `--limit N` loads a slice, to see how it looks before committing
+- Loading into a website that already has events requires `--force`, so you
+  don't accidentally mix imported history into live traffic
+- Values are truncated to Umami's column widths rather than failing a batch
+  two thirds of the way through
+
+Take a database dump first anyway. This writes directly to Umami's tables.
+
+## Development
+
+```sh
+python -m venv .venv && .venv/bin/pip install -e '.[dev,all]'
+.venv/bin/python -m pytest
+```
+
+The transform is pure functions over dicts, so the tests need no database.
+
+## Compatibility
+
+| | Verified against |
+|---|---|
+| Plausible CE | v3.1.0 and v3.2.1, ClickHouse 24.12 |
+| Umami | v3.3.1, PostgreSQL 16 |
+
+Plausible 3.1.0 to 3.2.1 changes nothing here: `events_v2` is identical in
+column names and types, and extracting the same 5,094 events under both
+versions and loading each produced the same sessions, the same visits and the
+same per-path pageview counts, with no differences at all.
+
+Correctness was checked by loading 5,094 real events from a live Plausible
+instance into a fresh Umami v3.3.1, then comparing Umami's own dashboard
+aggregation against the raw ClickHouse rows:
+
+| | Plausible raw | Umami dashboard |
+|---|---|---|
+| pageviews | 1537 | 1537 |
+| visitors (distinct `user_id`) | 883 | 883 |
+| visits (distinct `session_id`) | 1089 | 1089 |
+| top page | `/` 1522 | `/` 1522 |
+
+Zero events referenced a missing session, and a full second run of the same
+file wrote no new rows.
+
+Both projects change their schemas. If yours differ, the mapping tables above
+tell you what to check.
+
+## Licence
+
+MIT.

plausible2umami-0.1.0/README.md

@@ -0,0 +1,249 @@
+# plausible2umami
+
+Migrate **self-hosted** Plausible analytics into Umami v3, one event at a time.
+
+Most Plausible-to-Umami tools read Plausible's CSV export. That export is daily
+totals per dimension, not events, so those tools have to invent the sessions
+that Umami needs: attributes drawn independently from daily distributions,
+pageviews spread round-robin across synthetic visits. The daily chart ends up
+about right and every individual row is fiction.
+
+If you self-host Plausible you don't have to accept that. Your raw events are
+sitting in ClickHouse with real timestamps, real session ids, referrers and
+device data, one row per event. This tool reads those.
+
+## What it needs
+
+- Plausible Community Edition, self-hosted, with access to its ClickHouse
+  (the `events_v2` table)
+- Umami **v3.x on PostgreSQL**. v3 dropped MySQL and MariaDB, and this tool
+  targets v3 only. The v3 images live on Docker Hub as
+  `umamisoftware/umami:3.3.1` rather than ghcr, and the `postgresql-` tag
+  prefix is gone now that Postgres is the only option
+
+## Use
+
+Create the target website in Umami's UI first, then copy its id out of the
+tracking snippet.
+
+Find the Plausible site id and see how much data there is:
+
+```sh
+docker compose exec plausible_events_db clickhouse-client \
+  -q "SELECT site_id, count() AS events, min(timestamp), max(timestamp)
+      FROM plausible_events_db.events_v2 GROUP BY site_id"
+```
+
+Extract, inspect, load:
+
+```sh
+pip install 'plausible2umami[all] @ git+https://github.com/einsz/plausible2umami'
+
+plausible2umami extract --site-id 1 --out events.jsonl
+plausible2umami load --in events.jsonl --website-id <uuid> --dry-run
+plausible2umami load --in events.jsonl --website-id <uuid> \
+    --dsn postgres://umami:pass@localhost:5432/umami
+```
+
+If ClickHouse isn't reachable from where you're running this, which is common,
+skip `extract` and produce the same file from inside the container:
+
+```sh
+plausible2umami query --site-id 1        # prints the SQL
+
+docker exec <clickhouse-container> clickhouse-client \
+  -q "<that SQL> FORMAT JSONEachRow" | gzip > events.jsonl.gz
+```
+
+The output format is identical either way, and `load` reads `.gz` directly.
+Keep the query's `ORDER BY` if you write it out by hand: it groups each
+visitor's events together and puts identical events next to each other, which
+is what lets the loader stream a multi-gigabyte file in flat memory.
+
+### Large sites: extract one day at a time
+
+Do not run the single-query extract against a site with millions of events on a
+small server. The `ORDER BY` makes ClickHouse sort the whole result, and
+Plausible's own `low-resources.xml` caps threads while leaving sort memory
+unbounded, with `max_bytes_before_external_sort` at its default of 0, meaning
+it never spills to disk. On a 4 GB host with Plausible already resident, a
+13.5 million row sort takes the machine into swap.
+
+```sh
+plausible2umami query --site-id 1 --by-day --out /tmp/site1 > extract.sh
+sh extract.sh
+```
+
+That fetches a day per query, so no sort exceeds one day's rows, and it reads
+only the relevant parts because `site_id` and the date lead the table's primary
+key. One file per day means an interrupted run resumes rather than restarting,
+and the parts are concatenated at the end without recompression, since joined
+gzip members are valid gzip.
+
+This is safe because Plausible's `user_id` is a hash whose salt rotates daily,
+so every row for a given visitor falls inside one day. Chunking by day
+preserves exactly the grouping the loader depends on.
+
+### Scale, and what it costs in disk
+
+Both phases stream, so memory stays flat regardless of size. Disk does not.
+
+Measured on a real migration of 9,753,130 events spanning two and a half years,
+loaded into a fresh Umami v3.3.1:
+
+| | |
+|---|---|
+| Extract, gzipped JSONL | 127 MB |
+| Load time | 33 minutes |
+| Postgres afterwards | **9,179 MB** |
+| of which row data | 1,258 MB |
+| of which indexes | **7,539 MB** |
+| The same events in ClickHouse | **127 MiB** |
+
+Umami puts fifteen indexes on `website_event`, and they cost six times the data
+they index. Your events are the cheap part.
+
+Four of them index columns Plausible has no equivalent for, so they sit empty
+after an import: `page_title`, `tag`, `url_query`, and `event_name` unless you
+keep engagement events. Roughly 2 GB of index over nothing.
+
+Decide how much history you want before you start. `--since` filters at load
+time from an extract you already have, so changing your mind costs a flag
+rather than another trip to ClickHouse.
+
+## What actually maps
+
+The identity mapping is the part worth understanding, and it is easy to get
+backwards:
+
+| Plausible | Umami | Meaning |
+|---|---|---|
+| `user_id` | `session.session_id` | the visitor |
+| `session_id` | `website_event.visit_id` | the 30-minute visit |
+
+Plausible's `user_id` is a salted hash that rotates daily, so an imported Umami
+session is really a visitor-day. That is a property of Plausible's data model,
+not something this tool discards.
+
+### Copied directly
+
+| Plausible `events_v2` | Umami |
+|---|---|
+| `timestamp` | `created_at` |
+| `name` | `event_type` (1 pageview, 2 custom) and `event_name` |
+| `pathname` | `url_path`, `url_query` |
+| `hostname` | `hostname` |
+| `referrer` | `referrer_domain`, `referrer_path`, `referrer_query` |
+| `utm_source` `utm_medium` `utm_campaign` `utm_content` `utm_term` | same names |
+| `browser` | `session.browser` |
+| `operating_system` | `session.os` |
+| `screen_size` | `session.device` |
+| `country_code` | `session.country` |
+| `subdivision1_code` | `session.region` |
+| `city_name` | `session.city` |
+
+Plausible's `screen_size` is a bucket ("Desktop", "Mobile"), which is Umami's
+`device`. Umami's `screen` wants "1920x1080" and has no source here.
+
+### Left null, because Plausible never collected it
+
+`session.language`, `session.screen`, `session.distinct_id`, `page_title`, and
+the web-vitals columns (`lcp`, `inp`, `cls`, `fcp`, `ttfb`).
+
+City is mapped. The extract selects `city_name`, an ALIAS column that resolves `city_geoname_id` against Plausible's bundled
+`location_data_dict`, so no GeoNames table has to be shipped.
+
+Whether you get anything depends on your GeoIP database. Plausible only records
+`city_geoname_id` when it has a **city-level** one; with country-level data the
+id is 0 for every event and `session.city` ends up null.
+On the instance this was developed against, all 5,102 test events had id 0, so
+the mapping is verified only as far as the dictionary: `dictGet` resolves ids
+to names correctly ("Berlin", "New York City"), but no live event
+carrying a real id was ever migrated.
+
+If your Plausible predates the `city_name` alias, remove it from the extract
+query. The loader treats a missing `city_name` as null rather than failing.
+
+### Dropped, no Umami equivalent
+
+`scroll_depth`, `engagement_time`, the `revenue_*` fields, `click_id_param`,
+`acquisition_channel`, and `browser_version` / `operating_system_version`.
+
+### Filtered out by default
+
+Plausible emits an internal `engagement` event alongside pageviews, carrying
+`scroll_depth` and `engagement_time`. Umami has nowhere to put either, so
+importing them adds rows and no information while filling Umami's custom-events
+list with a single meaningless name.
+
+They are dropped unless you pass `--include-engagement`. The volume is worth
+knowing: on the site this was first tested against, 3,557 of 5,094 events were
+engagement. Filtering them left pageviews, visitors and visits identical and
+cut the row count by 70%.
+
+### Not implemented
+
+- **Custom event properties.** `meta.key` / `meta.value` would map to Umami's
+  `event_data` table. Custom event *names* are imported; their properties are
+  not.
+
+Nothing is fabricated. Every field outside the tables above lands as null.
+
+## Safety
+
+Re-running is safe. Every id is a UUIDv5 derived from the source data and the
+target website id, and every insert is `ON CONFLICT DO NOTHING`, so a load that
+dies partway through can just be run again. Rows already written are left
+alone.
+
+- `--dry-run` transforms everything and writes nothing, printing counts, the
+  date range and a sample of what would go in
+- `--limit N` loads a slice, to see how it looks before committing
+- Loading into a website that already has events requires `--force`, so you
+  don't accidentally mix imported history into live traffic
+- Values are truncated to Umami's column widths rather than failing a batch
+  two thirds of the way through
+
+Take a database dump first anyway. This writes directly to Umami's tables.
+
+## Development
+
+```sh
+python -m venv .venv && .venv/bin/pip install -e '.[dev,all]'
+.venv/bin/python -m pytest
+```
+
+The transform is pure functions over dicts, so the tests need no database.
+
+## Compatibility
+
+| | Verified against |
+|---|---|
+| Plausible CE | v3.1.0 and v3.2.1, ClickHouse 24.12 |
+| Umami | v3.3.1, PostgreSQL 16 |
+
+Plausible 3.1.0 to 3.2.1 changes nothing here: `events_v2` is identical in
+column names and types, and extracting the same 5,094 events under both
+versions and loading each produced the same sessions, the same visits and the
+same per-path pageview counts, with no differences at all.
+
+Correctness was checked by loading 5,094 real events from a live Plausible
+instance into a fresh Umami v3.3.1, then comparing Umami's own dashboard
+aggregation against the raw ClickHouse rows:
+
+| | Plausible raw | Umami dashboard |
+|---|---|---|
+| pageviews | 1537 | 1537 |
+| visitors (distinct `user_id`) | 883 | 883 |
+| visits (distinct `session_id`) | 1089 | 1089 |
+| top page | `/` 1522 | `/` 1522 |
+
+Zero events referenced a missing session, and a full second run of the same
+file wrote no new rows.
+
+Both projects change their schemas. If yours differ, the mapping tables above
+tell you what to check.
+
+## Licence
+
+MIT.

plausible2umami-0.1.0/pyproject.toml

@@ -0,0 +1,40 @@
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "plausible2umami"
+version = "0.1.0"
+description = "Migrate self-hosted Plausible analytics into Umami v3, event by event"
+readme = "README.md"
+license = "MIT"
+requires-python = ">=3.10"
+authors = [{ name = "einsz" }]
+keywords = ["plausible", "umami", "analytics", "migration", "clickhouse"]
+classifiers = [
+    "Development Status :: 4 - Beta",
+    "Environment :: Console",
+    "Intended Audience :: System Administrators",
+    "Programming Language :: Python :: 3",
+    "Topic :: Internet :: Log Analysis",
+]
+dependencies = []
+
+[project.urls]
+Homepage = "https://github.com/einsz/plausible2umami"
+Issues = "https://github.com/einsz/plausible2umami/issues"
+
+[project.optional-dependencies]
+extract = ["clickhouse-connect>=0.7"]
+load = ["psycopg[binary]>=3.1"]
+all = ["clickhouse-connect>=0.7", "psycopg[binary]>=3.1"]
+dev = ["pytest>=8"]
+
+[project.scripts]
+plausible2umami = "plausible2umami.cli:main"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/plausible2umami"]
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]

plausible2umami-0.1.0/src/plausible2umami/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.1.0"

plausible2umami-0.1.0/src/plausible2umami/__main__.py

@@ -0,0 +1,6 @@
+import sys
+
+from .cli import main
+
+if __name__ == "__main__":
+    sys.exit(main())