Skip to content

fix: run activation discovery from Base runtime - #2611

Merged
codeforester merged 2 commits into
mainfrom
bug/2610-20261018-basectl-activate-fails-when-project-venv-lacks-click
Oct 18, 2026
Merged

codeforester merged 2 commits into
mainfrom
bug/2610-20261018-basectl-activate-fails-when-project-venv-lacks-click

Conversation

@codeforester

@codeforester codeforester commented Oct 18, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • Run project activation-source discovery through the Base virtual environment while preserving the active project context.
  • Add an explicit base-wrapper option for selecting a venv without replacing BASE_PROJECT.
  • Keep discovery scoped to the active project manifest instead of scanning unrelated workspace siblings.

Fixes #2610

Validation

  • 54 focused BATS tests passed
  • ./bin/base-test: 1,823 passed
  • shellcheck -x bin/base-wrapper lib/bash/runtime/bashrc
  • git diff --check
  • Real bleach-style interactive runtime reproduction with Click absent from the project venv

Root cause

basectl setup installs Click in Base virtualenv, not every project virtualenv. Runtime startup was invoking activation discovery through the project Python, so a correctly isolated project environment without Click produced the misleading base_cli import error.

@codeforester
codeforester requested a review from a team as a code owner October 18, 2026 11:07
@codeforester

Copy link
Copy Markdown
Collaborator Author

Automated review findings

  1. Workaround addresses the symptom, not the root cause (lib/bash/runtime/bashrc ~line 141): the fix bolts on --project base --workspace <root> to force activation discovery through a different code path, instead of fixing the actual cause. bin/base-wrapper:114 unconditionally sets BASE_PROJECT="$project" (here "base") and exports it; project_discovery.py:72's resolve_active_project() checks os.environ.get("BASE_PROJECT") != project_name where project_name is the actual project being activated (e.g. "demo") - confirmed directly, this mismatch means the cheap, single-manifest-read shortcut is skipped unconditionally for every activation that mixes --project base with a different logical project name. A more targeted fix would be in base-wrapper itself - e.g. only setting BASE_PROJECT when unset, or using a separate venv-selection variable - rather than forcing every caller down the slow path and leaving the broken shortcut in place for the next caller that hits the same combination.

  2. New workspace-wide dependency for a single-project operation (lib/bash/runtime/bashrc ~line 142): forcing discovery through --workspace $BASE_PROJECT_ROOT/.. makes basectl activate <project> depend on every sibling project's manifest in the workspace being valid and uniquely named, not just the project being activated. activation_sources_project_command -> resolve_named_project -> find_named_project now always takes the workspace is not None path, which calls discover_projects_cached() -> read_project() on every sibling manifest, then validate_unique_project_names() across all of them. If any unrelated sibling project has a malformed manifest or a name collision, activation of the working project fails with "Unable to resolve project activation scripts," even though the project actually being activated is fine. The previous direct BASE_PROJECT_MANIFEST read only ever looked at the one project being activated and was immune to problems elsewhere in the workspace.

  3. Weakened test assertion (cli/bash/commands/basectl/tests/runtime-shell.bats ~line 9): the OR'd argument-position check added to the four pre-existing activation-source tests accepts both the old (now-unreachable) call shape and the new one, so these four tests no longer pin down the exact argv base_projects is invoked with. A future accidental regression that shifts the invocation shape back toward the old form would still pass these four tests - only the newly-added fifth test pins the current shape exactly.

Posted via Claude Code

@codeforester

Copy link
Copy Markdown
Collaborator Author

Addressed in commit 0cf5768.

  • Added --preserve-project-context to base-wrapper so Base can select its own virtualenv without overwriting the active project context.
  • Runtime activation discovery now uses that option and no longer forces a workspace-wide scan, so unrelated sibling manifests cannot block activation.
  • Tightened the runtime fixtures to require the isolated Base entrypoint argv instead of accepting both old and new forms.

Validation: 54 focused BATS tests, the full 1,823-test gate, production shellcheck, and the real bleach-style Click-missing reproduction all pass.

@codeforester
codeforester merged commit 9d7bd53 into main Oct 18, 2026
25 checks passed
@codeforester
codeforester deleted the bug/2610-20261018-basectl-activate-fails-when-project-venv-lacks-click branch October 18, 2026 15:54
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.

basectl activate fails when project venv lacks Click

1 participant