Skip to content

feat: let wrappers identify themselves in X-Sonilo-Client (0.5.1) - #12

Merged
spencer-zqian merged 3 commits into
mainfrom
feat/client-identity
Jul 23, 2026
Merged

feat: let wrappers identify themselves in X-Sonilo-Client (0.5.1)#12
spencer-zqian merged 3 commits into
mainfrom
feat/client-identity

Conversation

@spencer-zqian

Copy link
Copy Markdown
Contributor

Problem

The dashboard shows CLI calls as SDK (Python). Both first-party wrappers — sonilo-cli and sonilo-video-kit — construct a Sonilo() client, and the SDK hardcodes X-Sonilo-Client: sdk-python with no way to override it. So every CLI and video-kit call is indistinguishable from direct SDK use.

That matters because CLI and SDK users are different populations (scripts/ops/evaluation vs. product integration), and the split cannot be recovered retroactively — mixed history stays mixed.

This is out of step with the usual convention, where the CLI is its own client surface:

Vendor CLI SDK
AWS aws-cli/2.15.0 … botocore/1.34 boto3/1.34
Stripe stripe-cli/1.19 stripe-python/8.x
GitHub gh/2.x octokit/x

Change

Sonilo / AsyncSonilo take two new optional arguments:

Sonilo(client_name="cli-python", client_version="0.1.1")

Both default to sdk-python and the SDK's own version, so direct SDK use is unchanged. DEFAULT_CLIENT_NAME is exported for callers that want the default explicitly.

Resulting identities:

Caller X-Sonilo-Client X-Sonilo-Client-Version
Direct SDK use sdk-python SDK version (0.5.1)
sonilo-cli cli-python CLI version (0.1.1)
sonilo-video-kit kit-python-video kit version (0.1.2)

A caller-supplied client keeps whatever identity its owner gave it — only the video kit's internally constructed default clients (generate.py, duck.py) are tagged.

Why a patch release (0.5.1), not 0.6.0

Strict semver would call a new public parameter a minor bump. A 0.6.0 would break the package set: sonilo-cli and sonilo-video-kit both pin sonilo <0.6, so the CLI would need >=0.6 to use the new argument while the kit still demanded <0.6 — the exact ResolutionImpossible that #11 had to clean up.

The change is purely additive with defaults preserving current behavior, so 0.5.1 keeps every existing pin valid and leaves sonilo-video-kit's dependency untouched.

Version bumps

  • sonilo 0.5.0 → 0.5.1
  • sonilo-cli 0.1.0 → 0.1.1
  • sonilo-video-kit 0.1.1 → 0.1.2 (adds _version.py, which the package previously lacked)

Required follow-up outside this repo

⚠️ The dashboard must map the two new values, or CLI and kit traffic will render as an unknown source:

  • cli-pythonCLI (Python)
  • kit-python-videoVideo Kit (Python)

sonilo-js hardcodes sdk-js the same way and will need the equivalent hook before the JS CLI (sonilo-js#12) ships.

Test plan

  • pytest → 173 passed (6 new: defaults, independent overrides, async parity)
  • pytest sonilo-cli → 29 passed (1 new)
  • pytest sonilo-video-kit → 53 passed (1 new)
  • Verified the headers actually sent by each package:
    CLI              X-Sonilo-Client=cli-python        version=0.1.1
    SDK direct       X-Sonilo-Client=sdk-python        version=0.5.1
    video-kit default X-Sonilo-Client=kit-python-video version=0.1.2
    
  • Live sonilo account call against the production API succeeded via the CLI

The CLI and video kit both build on the SDK, so every call they made
reported as sdk-python — making CLI and kit traffic indistinguishable from
direct SDK use in server-side analytics, with no way to recover the split
retroactively.

Sonilo/AsyncSonilo now take optional client_name/client_version, defaulting
to sdk-python and the SDK version. The CLI sends cli-python and the video
kit sends kit-python-video, each with its own package version. A
caller-supplied client keeps its owner's identity; only the kit's internally
constructed default clients are tagged.

Released as a patch (0.5.1) rather than a minor: the change is purely
additive, and a 0.6.0 would have forced pin bumps and re-releases across
sonilo-cli and sonilo-video-kit, which pin <0.6.
@sapient-app

sapient-app Bot commented Jul 23, 2026

Copy link
Copy Markdown

Sapient docs evals

Waiting for the staging docs URL before running evals.

Sapient will start the selected PR evals automatically when GitHub reports a successful docs deployment for this PR. This usually happens within 15 minutes.

Commit: e60da8b
Status: waiting for staging docs URL

_default_client() builds Sonilo() without an explicit key, so the SDK reads
SONILO_API_KEY. The test passed locally only because a key happened to be
exported; CI has none and failed on both matrix entries.
The dashboard's source taxonomy is <surface>-<language> (sdk-js,
sdk-python). kit-python-video broke that ordering; videokit-python lines up
with cli-python and leaves room for videokit-js.
@spencer-zqian
spencer-zqian merged commit 154f80f into main Jul 23, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant