insightfactory-cli 1.0.0.dev4__tar.gz → 1.0.1__tar.gz

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/.github/workflows/release.yml

@@ -1,6 +1,8 @@
 name: release
 
-# CD: merge to develop/main (or a v* tag) publishes to public PyPI.
+# CD: a push to develop publishes a `.dev<run_number>` pre-release; a `v*` tag
+# publishes the release. A merge to main runs CI and publishes nothing -- see
+# if_s_insightfactory_cli.yml for why releasing is a deliberate tag push.
 # Verify + build live in insightfactory-ai/if_sre_github_actions
 # (if_s_insightfactory_cli.yml). The publish job stays here because PyPI
 # Trusted Publishing is registered for this repository, workflow `release.yml`,

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/CLAUDE.md

@@ -22,7 +22,11 @@ uv run ty check
   Node CLI (`~/.insightfactory`, `INSIGHTFACTORY_CONFIG_DIR` override).
 - Do not commit credentials, access tokens, refresh tokens, or client secrets.
 - Test fixtures use only neutral hostnames (`factory.example`).
-- Do not publish to PyPI or create release tags from a developer machine;
-  merges to `develop` / `main` (and optional `v*` tags) publish via the
-  reusable workflow in `if_sre_github_actions` plus the OIDC job in
-  `.github/workflows/release.yml`.
+- Do not publish to PyPI from a developer machine. Publishing happens in CI: the
+  reusable workflow in `if_sre_github_actions` builds and stages, and the OIDC job
+  in `.github/workflows/release.yml` uploads.
+- **A release is a pushed `v*` tag, not a merge.** Merging to `main` runs CI and
+  publishes nothing; pushing `v<version>` publishes that version, and the tag must
+  match `pyproject.toml`. Pushing `develop` publishes a `.dev{run_number}`
+  pre-release. Creating the release tag is a deliberate human act — do not create
+  or push one unless asked to cut a release.

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: insightfactory-cli
-Version: 1.0.0.dev4
+Version: 1.0.1
 Summary: Profile-based authentication CLI for the InsightFactory Interfaces API
 Project-URL: Homepage, https://github.com/insightfactory-ai/insightfactory-cli
 Project-URL: Repository, https://github.com/insightfactory-ai/insightfactory-cli
@@ -212,12 +212,16 @@ Python 3.10 or newer is required. Runtime code is stdlib-only.
 
 ## Release
 
-Publishing is automatic from GitHub Actions on merge. Verify and build live in
-the reusable workflow
+**A release is cut by pushing a tag, not by merging.** Merging to `main` runs CI and
+publishes nothing.
+
+```bash
+git tag v1.0.1 && git push origin v1.0.1
+```
+
+Verify and build live in the reusable workflow
 [`if_s_insightfactory_cli.yml`](https://github.com/insightfactory-ai/if_sre_github_actions/blob/main/.github/workflows/if_s_insightfactory_cli.yml)
-in `insightfactory-ai/if_sre_github_actions`
-([PR #300](https://github.com/insightfactory-ai/if_sre_github_actions/pull/300)
-must merge before these stubs go green). This repository's
+in `insightfactory-ai/if_sre_github_actions`. This repository's
 `.github/workflows/release.yml` keeps only the OIDC publish job, because PyPI
 Trusted Publishing is registered for **this** repo, workflow `release.yml`, and
 environment `pypi` — a reusable workflow cannot be registered.
@@ -228,24 +232,38 @@ the reusable workflow and uploads it with `pypa/gh-action-pypi-publish`.
 
 | Trigger | Published version | PyPI role |
 |---|---|---|
-| Push / merge to `develop` | `1.0.0.dev{N}` | pre-release (`pip install --pre`) |
-| Push / merge to `main` | `1.0.0` (the version in `pyproject.toml`) | latest |
-| Push of a `v*` tag | same as `main` | retry / explicit cut of that version |
+| Push / merge to `develop` | `1.0.1.dev{N}` | pre-release (`pip install --pre`) |
+| Push of a `v*` tag | the version in `pyproject.toml`, which the tag must match | latest |
+| Merge to `main` | nothing — CI only | — |
 
 `N` is `github.run_number` of the reusable workflow: a per-workflow integer
 that goes up on every run and stays the same across re-runs of that run (so a
 failed publish can be retried under the same version). It does not depend on
-git history or clone depth. After a successful `main` publish, bump `version`
-in `pyproject.toml` on `develop` so later `.devN` builds sort *after* what just
-landed; PEP 440 puts `1.0.0.devN` before `1.0.0`. Because of that ordering, a
+git history or clone depth. After a successful release, bump `version` in
+`pyproject.toml` on `develop` so later `.devN` builds sort *after* what just
+landed; PEP 440 puts `1.0.1.devN` before `1.0.1`. Because of that ordering, a
 dependency spec of `insightfactory-cli>=1.0.0` does not match develop-channel
 `.devN` builds; an in-process consumer that wants them must specify a
 pre-release-bearing spec such as `insightfactory-cli>=1.0.0.dev0` (which also
 matches the final `1.0.0` release).
 
-A version that is already on PyPI is skipped rather than failing, so a second
-push to `main` (or a `v*` tag for the same version) is a no-op. A `v*` tag
-whose name does not match `pyproject.toml` fails before publishing.
+A `v*` tag whose name does not match `pyproject.toml` fails before publishing.
+
+The two channels treat an already-published version differently, on purpose:
+
+- **Release channel (a tag):** publishing fails, naming the fix. A tag is a request to
+  release that version; if it cannot be honoured, the run must say so rather than report
+  success having published nothing. (git also refuses to push a tag that already exists,
+  so this is hard to reach.)
+- **Dev channel (`develop`):** publishing is skipped quietly. `.dev{N}` uses
+  `github.run_number`, which is stable across re-runs of one run, so an already-present
+  version there can only mean a re-run of a run that already published — real idempotency,
+  not a swallowed mistake.
+
+This split is why releasing moved off `main`. While a merge was the trigger, an
+already-published version *had* to be tolerated as a no-op for merges to stay green — so a
+merge that released nothing looked exactly like one that released, and a forgotten version
+bump shipped nothing silently.
 
 ## Differences from the Node CLI
 

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/README.md

@@ -196,12 +196,16 @@ Python 3.10 or newer is required. Runtime code is stdlib-only.
 
 ## Release
 
-Publishing is automatic from GitHub Actions on merge. Verify and build live in
-the reusable workflow
+**A release is cut by pushing a tag, not by merging.** Merging to `main` runs CI and
+publishes nothing.
+
+```bash
+git tag v1.0.1 && git push origin v1.0.1
+```
+
+Verify and build live in the reusable workflow
 [`if_s_insightfactory_cli.yml`](https://github.com/insightfactory-ai/if_sre_github_actions/blob/main/.github/workflows/if_s_insightfactory_cli.yml)
-in `insightfactory-ai/if_sre_github_actions`
-([PR #300](https://github.com/insightfactory-ai/if_sre_github_actions/pull/300)
-must merge before these stubs go green). This repository's
+in `insightfactory-ai/if_sre_github_actions`. This repository's
 `.github/workflows/release.yml` keeps only the OIDC publish job, because PyPI
 Trusted Publishing is registered for **this** repo, workflow `release.yml`, and
 environment `pypi` — a reusable workflow cannot be registered.
@@ -212,24 +216,38 @@ the reusable workflow and uploads it with `pypa/gh-action-pypi-publish`.
 
 | Trigger | Published version | PyPI role |
 |---|---|---|
-| Push / merge to `develop` | `1.0.0.dev{N}` | pre-release (`pip install --pre`) |
-| Push / merge to `main` | `1.0.0` (the version in `pyproject.toml`) | latest |
-| Push of a `v*` tag | same as `main` | retry / explicit cut of that version |
+| Push / merge to `develop` | `1.0.1.dev{N}` | pre-release (`pip install --pre`) |
+| Push of a `v*` tag | the version in `pyproject.toml`, which the tag must match | latest |
+| Merge to `main` | nothing — CI only | — |
 
 `N` is `github.run_number` of the reusable workflow: a per-workflow integer
 that goes up on every run and stays the same across re-runs of that run (so a
 failed publish can be retried under the same version). It does not depend on
-git history or clone depth. After a successful `main` publish, bump `version`
-in `pyproject.toml` on `develop` so later `.devN` builds sort *after* what just
-landed; PEP 440 puts `1.0.0.devN` before `1.0.0`. Because of that ordering, a
+git history or clone depth. After a successful release, bump `version` in
+`pyproject.toml` on `develop` so later `.devN` builds sort *after* what just
+landed; PEP 440 puts `1.0.1.devN` before `1.0.1`. Because of that ordering, a
 dependency spec of `insightfactory-cli>=1.0.0` does not match develop-channel
 `.devN` builds; an in-process consumer that wants them must specify a
 pre-release-bearing spec such as `insightfactory-cli>=1.0.0.dev0` (which also
 matches the final `1.0.0` release).
 
-A version that is already on PyPI is skipped rather than failing, so a second
-push to `main` (or a `v*` tag for the same version) is a no-op. A `v*` tag
-whose name does not match `pyproject.toml` fails before publishing.
+A `v*` tag whose name does not match `pyproject.toml` fails before publishing.
+
+The two channels treat an already-published version differently, on purpose:
+
+- **Release channel (a tag):** publishing fails, naming the fix. A tag is a request to
+  release that version; if it cannot be honoured, the run must say so rather than report
+  success having published nothing. (git also refuses to push a tag that already exists,
+  so this is hard to reach.)
+- **Dev channel (`develop`):** publishing is skipped quietly. `.dev{N}` uses
+  `github.run_number`, which is stable across re-runs of one run, so an already-present
+  version there can only mean a re-run of a run that already published — real idempotency,
+  not a swallowed mistake.
+
+This split is why releasing moved off `main`. While a merge was the trigger, an
+already-published version *had* to be tolerated as a no-op for merges to stay green — so a
+merge that released nothing looked exactly like one that released, and a forgotten version
+bump shipped nothing silently.
 
 ## Differences from the Node CLI
 

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "insightfactory-cli"
-version = "1.0.0.dev4"
+version = "1.0.1"
 description = "Profile-based authentication CLI for the InsightFactory Interfaces API"
 readme = "README.md"
 requires-python = ">=3.10"

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/tests/test_cli.py

@@ -2,6 +2,7 @@ from __future__ import annotations
 
 import json
 import shutil
+from importlib.metadata import version
 from pathlib import Path
 
 import pytest
@@ -112,7 +113,11 @@ def test_an_unknown_command_fails_with_the_command_reference():
 def test_version_prints_the_package_version():
     result = run_cli(["--version"])
     assert result.returncode == 0
-    assert result.stdout.strip() == "1.0.0"
+    # Compare against the installed metadata, which is the same source main.py
+    # reads, rather than a literal. The property under test is that --version
+    # reports the package's own version -- not what that version happens to be --
+    # so a release bump should not have to edit this test.
+    assert result.stdout.strip() == version("insightfactory-cli")
 
 
 def test_login_parses_profile_host_and_no_browser_flags():

{insightfactory_cli-1.0.0.dev4 → insightfactory_cli-1.0.1}/uv.lock

@@ -34,7 +34,7 @@ wheels = [
 
 [[package]]
 name = "insightfactory-cli"
-version = "1.0.0"
+version = "1.0.1"
 source = { editable = "." }
 
 [package.dev-dependencies]