insightfactory-cli 1.1.0.dev22__tar.gz → 1.1.1.dev25__tar.gz

insightfactory_cli-1.1.1.dev25/.github/workflows/release.yml

@@ -0,0 +1,94 @@
+name: release
+
+# CD: a push to develop publishes a `.dev<run_number>` pre-release; a `v*` tag
+# creates the GitHub Release and publishes it to PyPI. 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`,
+# and environment `pypi` — a reusable workflow cannot be registered.
+on:
+  push:
+    branches: [develop, main]
+    tags:
+      - "v*"
+
+concurrency:
+  group: release-${{ github.ref }}
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  ci:
+    uses: insightfactory-ai/if_sre_github_actions/.github/workflows/if_s_insightfactory_cli.yml@main
+    secrets: inherit
+    permissions:
+      # The central workflow's release job creates the GitHub Release for the pushed
+      # tag, which needs `contents: write`. A called workflow may only reduce the
+      # caller's grant, never raise it, so the grant has to be made here. ci.yml
+      # stays read-only: its release job is push-gated and simply never runs.
+      contents: write
+
+  publish:
+    name: Publish to PyPI
+    needs: ci
+    if: needs.ci.outputs.should_publish == 'true'
+    runs-on: ${{ vars.RUN_LINUX }}
+    timeout-minutes: 10
+    environment:
+      name: pypi
+      url: https://pypi.org/p/insightfactory-cli
+    permissions:
+      id-token: write
+      # Publishing the draft Release the central workflow created. A job-level
+      # block replaces the set rather than adding to it, so id-token has to be
+      # repeated here.
+      contents: write
+    steps:
+      - uses: actions/download-artifact@v6
+        with:
+          name: dist-release
+          path: dist/
+
+      - uses: pypa/gh-action-pypi-publish@release/v1
+
+      # Only now, with the files actually on PyPI, does the Release stop being a
+      # draft: its body tells people to `pip install insightfactory-cli==X` and
+      # links the PyPI page, so publishing it any earlier would show instructions
+      # that 404, and leave them showing if this upload failed.
+      #
+      # Two details, both because this step runs after a successful upload and so
+      # must not be the thing that breaks:
+      #
+      #   TAG is github.ref_name, not an output of the called workflow. On a tag
+      #   push it is the tag, locally and unconditionally, and cannot drift if that
+      #   workflow is edited.
+      #
+      #   `make_latest: legacy` asks GitHub to pick Latest by version and date.
+      #   `gh release edit --latest` marks this release Latest outright, and the
+      #   concurrency group above is per-ref, so two tags can be in flight at once
+      #   and an older one finishing last would take the badge from the newer
+      #   release. The flag cannot express legacy, hence the raw API call.
+      - name: Publish the draft GitHub Release
+        if: startsWith(github.ref, 'refs/tags/v')
+        env:
+          GH_TOKEN: ${{ github.token }}
+          GH_REPO: ${{ github.repository }}
+          TAG: ${{ github.ref_name }}
+        run: |
+          set -euo pipefail
+          # The list endpoint, because get-by-tag does not return drafts. One page:
+          # a release created moments ago is among the newest.
+          id=$(gh api "repos/${GH_REPO}/releases?per_page=100" \
+                 --jq 'map(select(.tag_name == env.TAG)) | first | .id')
+          if [ -z "$id" ] || [ "$id" = "null" ]; then
+            echo "::error::${TAG} is on PyPI but has no GitHub Release to publish. Re-run the release job for this tag."
+            exit 1
+          fi
+          gh api -X PATCH "repos/${GH_REPO}/releases/${id}" \
+            -F draft=false \
+            -f make_latest=legacy \
+            --jq '.html_url'

insightfactory_cli-1.1.1.dev25/CHANGELOG.md

@@ -0,0 +1,125 @@
+# Changelog
+
+All notable changes to `insightfactory-cli` are recorded here.
+
+The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this
+project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+The release job reads the section whose heading matches the version in
+`pyproject.toml` and makes it the body of the GitHub Release. CI holds both ends of
+that: a PR into `develop` or `main` must raise the version and add its section here,
+and a tag whose version has no section fails rather than releasing an empty page.
+
+## 1.1.1
+
+### Added
+
+- This changelog, and `tools/release_notes.py`, which renders a version's section
+  plus install instructions as the GitHub Release body.
+- A `release-guard` CI job. A PR into `develop` or `main` that does not raise the
+  version in `pyproject.toml` and document it here now fails, instead of landing
+  under a section written for someone else's work.
+
+### Changed
+
+- Pushing a `v*` tag now creates the GitHub Release with the wheel and sdist
+  attached, instead of stopping at PyPI and leaving the Release to be made by hand.
+  The Release is drafted first and published once PyPI has the files, so its
+  install instructions never point at a version that is not there yet.
+
+## 1.1.0
+
+First release since 1.0.2. Two features: an MCP server that fronts several factory
+environments at once, and a login callback page that looks like the rest of the login.
+
+### Added
+
+- **`if-cli mcp`.** One MCP server over stdio, fronting several factory environments
+  as a single tool catalogue rather than one connection per environment. Every tool
+  takes a required `environment` argument, and each call goes to that environment's
+  own `/mcp` with that environment's profile. A profile's bearer token never reaches
+  another environment's host. Needs the `mcp` extra; the base install stays
+  dependency-free.
+- Named factory sections in `~/.insightfactory/config`, which is where the router
+  reads its environments and its `writable` list. Writes are allowed only on the
+  environments named there. Everywhere else the router allows an allowlist of tools
+  known to read, so a tool it has not heard of is refused rather than assumed safe.
+- A tool is published only on the environments whose input schema matches the
+  catalogue's, so a factory on an older release is never handed argument shapes it
+  does not accept.
+- Databricks connect prompts. A tool that runs under your personal Databricks
+  identity used to fail with a refusal naming no page. The router now names the page
+  to visit, taken from the factory rather than a hardcoded route, and only when that
+  page is on the environment's own origin. The prompt never goes to the model:
+  linking a Databricks identity should be a deliberate trip to a page, not a link
+  offered mid tool call.
+- `--read-only`, and a `--timeout` whose scope is documented.
+
+### Changed
+
+- The loopback callback page after `if-cli login` is themed to match Auth0 Universal
+  Login, replacing the bare HTML it used to show.
+
+### Fixed
+
+- A force-refreshed token no longer re-serves the token that was just rejected. The
+  refresh ran, the cached access token came back unchanged, and the 401 repeated.
+- The router no longer blocks `initialize` on building its catalogue. It retries a
+  failed build, revalidates environments once they become reachable, and no longer
+  waits on an in-flight build at shutdown, so one slow factory cannot hold up the
+  handshake.
+- `tools/list` pagination is followed, so a factory with more than one page of tools
+  publishes all of them.
+- An unsupported repeat option dies loudly instead of being ignored.
+
+## 1.0.2
+
+### Added
+
+- `timeout` can be raised per invocation on the programmatic API, for a call that is
+  expected to run long.
+
+### Fixed
+
+- The timeout override no longer reaches the OAuth transport, where a long timeout
+  would have applied to token calls that should stay short.
+- A misplaced HTTP method is named as such instead of the error blaming the path,
+  and the correction keeps the target you supplied.
+
+### Changed
+
+- The package carries a proprietary licence and ships `LICENSE` in the wheel.
+
+## 1.0.1
+
+### Fixed
+
+- Attached short-option values (`-ovalue`) and inline boolean values parse correctly.
+- Positional argument order for the `api` and `config` commands.
+- Exit status is preserved when stdout closes on Python 3.14.
+
+### Changed
+
+- The Claude review workflow no longer caps its own permissions, which had stopped it
+  starting at all.
+
+## 1.0.0
+
+First production release of the Python `if-cli`, the successor to the Node
+`@insightfactory-ai/if-cli`.
+
+### Added
+
+- `login`, `logout`, `profiles`, `token`, `set-token`, `config` and `api`, for
+  per-environment OAuth login and calling the Interfaces API from the command line.
+  OAuth is authorization-code with PKCE against a loopback-only callback; the CLI is
+  a public client with no secret.
+- Runtime code is stdlib-only, so the base install pulls in nothing.
+- On-disk profile and token-cache paths, JSON shapes and file permissions stay
+  byte-compatible with the Node CLI, so you can switch implementations without
+  logging in again.
+- A supported in-process API: `if_cli.config.load_config`,
+  `if_cli.config.get_profile`, `if_cli.oauth.get_valid_token` and
+  `if_cli.runtime.CliError`. These raise `CliError` rather than exiting, never write
+  to stdout, and never block on a browser or on input. Changing any of them requires
+  a major version bump.

{insightfactory_cli-1.1.0.dev22 → insightfactory_cli-1.1.1.dev25}/CLAUDE.md

@@ -34,3 +34,9 @@ uv run ty check
   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.
+- **Every PR into `develop` or `main` raises `version` in `pyproject.toml` and
+  documents that version in `CHANGELOG.md`.** The `release-guard` job runs
+  `tools/check_release.py` and fails the PR otherwise. Put user-visible changes in
+  the Added/Changed/Fixed group that fits; for internal-only work (tests, CI, a
+  refactor nothing observes) a one-line entry saying so is enough. The section
+  becomes the body of that version's GitHub Release.

{insightfactory_cli-1.1.0.dev22 → insightfactory_cli-1.1.1.dev25}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: insightfactory-cli
-Version: 1.1.0.dev22
+Version: 1.1.1.dev25
 Summary: Profile-based authentication CLI for the InsightFactory Interfaces API
 Project-URL: Homepage, https://insightfactory.ai
 Author-email: "insightfactory.ai Support" <support@insightfactory.ai>
@@ -340,6 +340,35 @@ and publishes nothing.
 git tag v1.0.1 && git push origin v1.0.1
 ```
 
+The tag drafts the GitHub Release, uploads to PyPI, then publishes the Release.
+Everything comes from one build, so the wheel and sdist attached to the Release
+are the files that went to PyPI, and the draft means nobody sees `pip install
+insightfactory-cli==1.1.1` on a Release page before that version exists on PyPI.
+A failed upload leaves a draft rather than a published page pointing at a 404.
+
+The body comes from [`CHANGELOG.md`](CHANGELOG.md) via `tools/release_notes.py`.
+It covers the tagged version and any version opened since the last tag, because
+one version per PR means unreleased versions pile up between tags: if 1.1.1 and
+1.1.2 both merge and only `v1.1.2` is tagged, 1.1.1's code ships inside that
+artifact, so its notes belong on that Release. A checkout with no tags falls back
+to the tagged version's section alone.
+
+`develop` therefore carries the version the next release will use, and the
+`release-guard` job holds it there. A PR into `develop` must raise `version` in
+`pyproject.toml` above what `develop` already has, and must add that version's
+`CHANGELOG.md` section. `tools/check_release.py` runs both checks and is what
+fails the PR:
+
+```bash
+BASE=origin/develop python3 tools/check_release.py
+```
+
+One version per PR, then. The instinct is to let a second change join the
+section the first one opened, and the guard refuses that: the version would be
+tagged with notes that do not describe everything in it, and nothing stops the
+tag going out between the two merges. Bump the patch number again, or fold the
+second change into the first PR.
+
 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`. This repository's
@@ -354,7 +383,7 @@ reusable workflow and uploads it with `pypa/gh-action-pypi-publish`.
 | Trigger | Published version | PyPI role |
 |---|---|---|
 | 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 |
+| Push of a `v*` tag | the version in `pyproject.toml`, which the tag must match | latest, plus a GitHub Release |
 | Merge to `main` | nothing, CI only | none |
 
 `N` is `github.run_number` of the reusable workflow. It is a per-workflow

{insightfactory_cli-1.1.0.dev22 → insightfactory_cli-1.1.1.dev25}/README.md

@@ -316,6 +316,35 @@ and publishes nothing.
 git tag v1.0.1 && git push origin v1.0.1
 ```
 
+The tag drafts the GitHub Release, uploads to PyPI, then publishes the Release.
+Everything comes from one build, so the wheel and sdist attached to the Release
+are the files that went to PyPI, and the draft means nobody sees `pip install
+insightfactory-cli==1.1.1` on a Release page before that version exists on PyPI.
+A failed upload leaves a draft rather than a published page pointing at a 404.
+
+The body comes from [`CHANGELOG.md`](CHANGELOG.md) via `tools/release_notes.py`.
+It covers the tagged version and any version opened since the last tag, because
+one version per PR means unreleased versions pile up between tags: if 1.1.1 and
+1.1.2 both merge and only `v1.1.2` is tagged, 1.1.1's code ships inside that
+artifact, so its notes belong on that Release. A checkout with no tags falls back
+to the tagged version's section alone.
+
+`develop` therefore carries the version the next release will use, and the
+`release-guard` job holds it there. A PR into `develop` must raise `version` in
+`pyproject.toml` above what `develop` already has, and must add that version's
+`CHANGELOG.md` section. `tools/check_release.py` runs both checks and is what
+fails the PR:
+
+```bash
+BASE=origin/develop python3 tools/check_release.py
+```
+
+One version per PR, then. The instinct is to let a second change join the
+section the first one opened, and the guard refuses that: the version would be
+tagged with notes that do not describe everything in it, and nothing stops the
+tag going out between the two merges. Bump the patch number again, or fold the
+second change into the first PR.
+
 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`. This repository's
@@ -330,7 +359,7 @@ reusable workflow and uploads it with `pypa/gh-action-pypi-publish`.
 | Trigger | Published version | PyPI role |
 |---|---|---|
 | 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 |
+| Push of a `v*` tag | the version in `pyproject.toml`, which the tag must match | latest, plus a GitHub Release |
 | Merge to `main` | nothing, CI only | none |
 
 `N` is `github.run_number` of the reusable workflow. It is a per-workflow

{insightfactory_cli-1.1.0.dev22 → insightfactory_cli-1.1.1.dev25}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "insightfactory-cli"
-version = "1.1.0.dev22"
+version = "1.1.1.dev25"
 description = "Profile-based authentication CLI for the InsightFactory Interfaces API"
 readme = "README.md"
 requires-python = ">=3.10"
@@ -39,6 +39,11 @@ packages = ["src/if_cli"]
 [tool.pytest.ini_options]
 testpaths = ["tests"]
 
+[tool.ty.environment]
+# tools/ is not part of the package, so the scripts there are reached by path at
+# runtime (sys.path.append) and ty needs telling where they live.
+extra-paths = ["tools"]
+
 [tool.ruff]
 target-version = "py310"
 line-length = 120