fix: make the CLI usable without the bigquery extra - #86
Merged
Conversation
`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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pip install bizonwith no extras produces a CLI that cannot start at all. Every command —bizon --helpincluded — dies with: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
fileorloggerdestination.Cause
bizon.common.modelsimports every destination config unconditionally (pydantic needs the classes to build the discriminated union). The BigQuery config importstable_namingpurely for theBIZON_TABLE_PREFIXstring constant, andtable_namingimported google at module level — so the entire CLI transitively depended on thebigqueryextra.I checked the rest of that chain:
table_namingwas 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 behindTYPE_CHECKINGwithfrom __future__ import annotations.Verified
google.cloud.bigquerygenuinely absent):bizon --helpandbizon source listwork, and adummy → filepipeline runs to completion — 5 rows written.import bizon.cli.mainnow pulls in zero optional dependencies.Regression test
tests/cli/test_cli_imports.pyasserts onsys.modulesin a subprocess rather than catching anImportError, 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:Worth a 0.5.1 once merged, since 0.5.0 ships the bug.
🤖 Generated with Claude Code