fix: install tqdm, which the pinned engine imports but does not require - #84
Merged
Conversation
Every run currently fails at "ModuleNotFoundError: No module named 'tqdm'". The pinned CodeBoarding CLI imports tqdm from codeboarding_cli/commands/full_analysis.py, which main.py imports unconditionally, so nothing runs, not just full analyses. tqdm is not among codeboarding's dependencies; it arrived through openai, and openai 3.3.0 dropped it. Pinning codeboarding==0.13.8 never pinned what its dependencies resolve to, so the same install started failing without anything here changing. Naming tqdm in the install is a workaround for that packaging gap and should go once the engine declares it. The install now also checks the CLI starts, so a missing dependency fails at the install step with a reason instead of surfacing as a traceback part way through an analysis. It runs the console script rather than `python -c 'import main'`: the latter puts the analyzed repository's own main.py ahead of the CLI's on sys.path, which many Python projects have. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
CodeBoarding reviewStatus: 0 changed components See the full change in CodeBoarding. graph LR
n_Visual_Rendering_Engine["Visual Rendering Engine"]
n_Structural_Diff_Engine["Structural Diff Engine"]
n_Interaction_Orchestrator["Interaction Orchestrator"]
n_Visual_Rendering_Engine -- "Returns rendering metadata and diagram artifacts" --> n_Interaction_Orchestrator
n_Structural_Diff_Engine -- "Provides annotated diff model for visualization" --> n_Visual_Rendering_Engine
n_Interaction_Orchestrator -- "Triggers structural comparison via CLI" --> n_Structural_Diff_Engine
classDef added fill:#1f883d,stroke:#0b5d23,color:#ffffff;
classDef modified fill:#bf8700,stroke:#7d4e00,color:#ffffff;
classDef deleted fill:#cf222e,stroke:#82071e,color:#ffffff,stroke-dasharray:5 3;
|
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.
Every CodeBoarding run is currently failing, on
@v1and@v2, with:Why now, when nothing here changed
tqdmincodeboarding_cli/commands/full_analysis.py, whichmain.pyimports unconditionally — so nothing runs, not just full analyses.tqdmis not a declared dependency ofcodeboarding.openai.openai3.3.0 droppedtqdmfrom its requirements.Pinning
codeboarding==0.13.8pins the release, not what its dependencies resolve to, so the same install line started producing a CLI that cannot start.Verified rather than inferred: a venv resolved a few hours before the breakage has
openai 3.1.0, whose metadata still liststqdm, and the CLI runs. A fresh resolve today givesopenai 3.3.0and notqdm:What this does
Names
tqdmin the install. That is a workaround for a packaging gap in the engine, commented as such, and should be removed oncecodeboardingdeclares its own dependency — the real fix belongs upstream, in the engine'spyproject.toml.It also checks the CLI can start, so a missing dependency fails at the install step with a stated reason instead of surfacing as a traceback part way into an analysis, after the progress comment has been posted.
That check runs the console script, not
python -c 'import main'.python -cputs the current directory onsys.path, and the current directory is the workspace, so any analyzed repository with its ownmain.pywould shadow the CLI's. Confirmed both ways against a straymain.py:python -c 'import main'imported the local file, the console script did not.Follow-up worth considering
This will recur. The action pins one package but installs an unpinned transitive graph, so any dependency of a dependency can break every consumer overnight. A constraints file, or
pip install --require-hashesagainst a lock, would make the install reproducible. Out of scope here — this PR is the unblock.🤖 Generated with Claude Code