From 01df5bc604922c82d97474a231006da528ed1626 Mon Sep 17 00:00:00 2001 From: Peter Freiberg <109841928+sabbaticas@users.noreply.github.com> Date: Mon, 17 Aug 2026 14:14:55 +1000 Subject: [PATCH] Correct the kospex pin wording in CLAUDE.md CLAUDE.md said in two places that kospex uses an exact `panopticas==` pin in its pyproject.toml, and that bumping it is mandatory because releases do not reach kospex otherwise. Checked against the kospex checkout: pyproject.toml has `panopticas>=0.0.19`, changed deliberately in kospex commit 527bcf3. The real situation is that kospex pins in two places, differently: pyproject.toml panopticas>=0.0.19 floor requirements.txt panopticas==0.0.19 exact So a PyPI install of kospex picks up a new panopticas release automatically, while a requirements.txt install stays put until regenerated. Release step 8 now says to read both files and explains which one actually needs updating every release. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 530df35..f7ba83f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -189,7 +189,15 @@ web content, not repository documentation. ```bash gh release create vX.Y.Z --title "vX.Y.Z" --notes-file CHANGELOG.md ``` -8. Update `panopticas==X.Y.Z` in kospex's `pyproject.toml` — kospex uses an **exact pin**, so a new release does not reach it until this is bumped. This step is mandatory, not conditional. +8. Update kospex's dependency on panopticas. Read both files rather than + assuming — they are pinned differently, and the difference decides whether + this step is urgent: + - `pyproject.toml` uses a **floor** (`panopticas>=X.Y.Z`), so a PyPI install + of kospex picks up a new release without any change here. Raise the floor + only when kospex starts depending on something the new release added. + - `requirements.txt` uses an **exact** pin (`panopticas==X.Y.Z`), so + development and deployment installs stay on the old version until it is + regenerated. Do this for every release. ## Relationship to kospex @@ -198,6 +206,13 @@ Panopticas is used by kospex for file type detection and metadata extraction. Ke - `kospex_git.py` calls `get_filename_metatypes()` and stores the result as `tech_type` - `kospex_schema.py` encodes tags as `|tag1|tag2|`; `kospex_query.py` queries them with `tech_type LIKE '%|tag|%'` - `kospex_core.py` tracks `last_panopticas_version` and re-syncs when it changes, so a version bump re-tags already-synced repos -- kospex pins `panopticas==X.Y.Z` in its `pyproject.toml` — an **exact** pin, so releases do not flow through until it is bumped. Read the current value from kospex's `pyproject.toml` rather than trusting a version quoted here; this line claimed `0.0.16` long after kospex had moved to `0.0.17` +- kospex pins panopticas in two places, differently: a **floor** in + `pyproject.toml` (`panopticas>=X.Y.Z`) and an **exact** pin in + `requirements.txt` (`panopticas==X.Y.Z`). A PyPI install of kospex therefore + picks up a new panopticas release automatically; a `requirements.txt` install + does not. Read both files for the current values rather than trusting any + version quoted here — this entry claimed an exact `pyproject.toml` pin long + after kospex had moved to `>=`, and before that quoted `0.0.16` when kospex + was on `0.0.17` When making breaking changes to panopticas, check kospex integration points first. Adding a tag is safe; renaming or removing one is not, since kospex stores tags in a database that is only refreshed on re-sync.