get-qry 0.1.0

The Qry Cloud CLI and dbt publisher

get-qry

The Qry Cloud command-line interface and dbt publisher. The PyPI distribution is named get-qry; the installed command is qry.

First run

pipx install get-qry
# or: uv tool install get-qry

qry auth signup
cd your-dbt-project
qry init
dbt build
qry dbt publish

qry dbt publish reads the same selected target from profiles.yml that dbt uses. DuckDB targets are copied from the local database file. Snowflake targets are read directly with a bounded, read-only query and materialized into the release artifact on the machine running the CLI. Qry Cloud never receives the warehouse credential. Password and private_key_path Snowflake profiles are supported; key-pair authentication is recommended.

Use the target stored by qry init --dbt-target, override it with --dbt-target, and set a non-default profiles directory with DBT_PROFILES_DIR or --profiles-dir.

qry auth signup and qry auth login open a short-lived browser authorization. New accounts confirm their email before approving the terminal. The CLI stores the resulting user session outside the repository and never prints it. qry init detects dbt_project.yml, creates or selects a workspace, registers the project and production environment, and writes a secret-free qry.toml.

Useful context commands:

qry status
qry workspace list
qry workspace create "Acme Data" --use
qry workspace use acme-data

For CI, create a project- and environment-scoped deploy token while signed in:

qry tokens create --name "GitHub Actions"

The raw qry_deploy_... value is revealed once. Store it as QRY_DEPLOY_TOKEN in the CI secret store. Public endpoint API keys are a separate credential class and cannot publish dbt releases.

After publishing, create a reveal-once key for a specific public endpoint:

qry keys create --endpoint customer_order_history --name "Local development"

Endpoint scope is required by default. A broader key requires the explicit --workspace-wide switch.

Automation

Non-interactive stdout is JSON by default. --json and --no-input can appear before or after the command:

qry status --json
qry init --workspace acme --no-input --json
qry dbt publish --json

Success uses {"data": ...}. Failures use a stable {"error":{"code","message","retryable"}} envelope on stderr and a nonzero exit status. Secrets are never included in status, workspace, auth, or project configuration output; reveal-once token creation is the explicit exception. Headless login does not launch a browser: it emits an authorization_required event with the verification URL and user code on stderr, then waits for approval.

Configuration is resolved in this order: command flags, environment variables, the nearest qry.toml, then the active user profile. Set QRY_CONFIG_HOME or XDG_CONFIG_HOME to isolate profiles in an agent or test sandbox.

Release

The Release get-qry GitHub workflow tests Python 3.10 through 3.13, builds and checks both distributions, and smoke-installs the wheel. Publishing uses PyPI Trusted Publishing from the pypi GitHub environment.

After configuring that publisher in PyPI, release version 0.1.0 by pushing the matching get-qry-v0.1.0 tag. The workflow rejects tags that do not match the version in pyproject.toml.