Skip to content

fix: make the CLI usable without the bigquery extra - #86

Merged
anaselmhamdi merged 1 commit into
mainfrom
anaselmhamdi/fix-bare-install-import
Aug 6, 2026
Merged

fix: make the CLI usable without the bigquery extra#86
anaselmhamdi merged 1 commit into
mainfrom
anaselmhamdi/fix-bare-install-import

Conversation

@anaselmhamdi

Copy link
Copy Markdown
Collaborator

pip install bizon with no extras produces a CLI that cannot start at all. Every command — bizon --help included — dies with:

ImportError: cannot import name 'bigquery' from 'google.cloud'

Pre-existing, not from #84. v0.4.1 fails identically in a clean venv; I found it while smoke-testing the v0.5.0 artifact from PyPI. It has presumably gone unnoticed because nearly everyone installs an extra — but it makes the advertised base package unusable, including for anyone who only wants the file or logger destination.

Cause

bizon.common.models imports every destination config unconditionally (pydantic needs the classes to build the discriminated union). The BigQuery config imports table_naming purely for the BIZON_TABLE_PREFIX string constant, and table_naming imported google at module level — so the entire CLI transitively depended on the bigquery extra.

I checked the rest of that chain: table_naming was the only heavy module-level import across all five destination config modules. The other two BigQuery configs reach it the same way, for the same constant.

Fix

Import google inside resolve_default_table_id() — the only thing that needs it, and only reached when a BigQuery destination is actually writing. The type annotation moves behind TYPE_CHECKING with from __future__ import annotations.

Verified

  • Installed this tree with no extras into a fresh venv (confirming google.cloud.bigquery genuinely absent): bizon --help and bizon source list work, and a dummy → file pipeline runs to completion — 5 rows written.
  • import bizon.cli.main now pulls in zero optional dependencies.
  • Full suite: 285 passed, nothing failing outside the pre-existing GCP-credential set.

Regression test

tests/cli/test_cli_imports.py asserts on sys.modules in a subprocess rather than catching an ImportError, so it fails in a dev environment where every extra is installed — otherwise it would be vacuous in CI. I confirmed it fails on the pre-fix code:

AssertionError: Importing bizon.cli.main pulled in optional dependencies:
['google.cloud.bigquery']. Every CLI command will fail on an install
without the matching extra. Import these lazily, inside the function that needs them.

Worth a 0.5.1 once merged, since 0.5.0 ships the bug.

🤖 Generated with Claude Code

`pip install bizon` with no extras produced a CLI that could not start at
all -- `bizon --help`, `bizon source list`, every command died with:

    ImportError: cannot import name 'bigquery' from 'google.cloud'

`bizon.common.models` imports every destination config unconditionally,
because pydantic needs the classes to build the discriminated union. The
BigQuery config imported `table_naming` purely for the BIZON_TABLE_PREFIX
constant, and that module imported google at module level -- so the whole
CLI depended on an optional extra. It affected anyone using only the `file`
or `logger` destination.

Import google inside resolve_default_table_id, which is the only thing that
needs it and only runs when a BigQuery destination is actually writing.

Pre-existing, not introduced by the stream-reset work: v0.4.1 fails
identically in a clean venv. Found while smoke-testing the v0.5.0 artifact
from PyPI.

Verified by installing this tree with no extras into a fresh venv: the CLI
starts and a dummy -> file pipeline runs to completion (5 rows).

The regression test asserts on sys.modules in a subprocess rather than on an
ImportError, so it also catches the regression in a dev environment where
every extra happens to be installed. Confirmed it fails on the pre-fix code.

Co-Authored-By: Claude <noreply@anthropic.com>
@anaselmhamdi
anaselmhamdi requested a review from aballiet August 6, 2026 08:46
@anaselmhamdi
anaselmhamdi merged commit e4f2395 into main Aug 6, 2026
1 check 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