00 Setup

Facilitator companion to the learner lesson 00 Setup.

Timing

About 30 minutes total. This is pre-work, not day-of content — push it out to partners before the session and confirm completion the day before, not the morning of. Nothing here is unattended in the "run it and walk away" sense; it is five tool installs, two account signups, a clone, and two virtualenv builds, all of which need a partner's hands on the keyboard the whole time. A partner who shows up having skipped it costs roughly 30 minutes of session time to recover live, at the expense of whatever module 01 was supposed to cover in that slot.

Talk track

• Frame this module as plumbing, not content: two clouds (Snowflake as source, ClickHouse Cloud as target), two dbt adapters, one per cloud, and both adapters share a hard Python floor.
• The one fact worth saying out loud, more than once: dbt-snowflake and dbt-clickhouse both require Python 3.11, 3.12, or 3.13. Python 3.14+ breaks a shared transitive dependency, mashumaro, in both adapters.
• Point at the two separate virtualenvs — workshop_public/snowflake_migration_lab/01-setup-snowflake/.venv and workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/.venv — and explain why they cannot be merged into one: the two adapters pin conflicting dependency ranges.
• Encourage both cloud signups now, not on the day: neither the Snowflake trial nor the ClickHouse Cloud trial should be a blocker once module 01 starts.

Common failures

• Python 3.14+ breaks dbt-snowflake and dbt-clickhouse via mashumaro. This is the module's headline failure, and the most dangerous one, because pinning the interpreter incorrectly does not fail here — it surfaces two modules later as a confusing dbt import error that has nothing obviously to do with a Python version. Confirm python3 --version reports 3.11, 3.12, or 3.13 for the interpreter actually behind each virtualenv — workshop_public/snowflake_migration_lab/01-setup-snowflake/.venv and workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/.venv — not just the system default — before signing a partner off on this module.
• TODO: no other failure mode for this module is documented in the lab's own README. Capture anything else observed in rehearsal here (corporate proxy or firewall blocking pip install or terraform init, Docker Desktop licensing prompts on first launch, trial-signup approval delays).

Reset steps

• Wrong Python version behind a venv: cd into whichever module's virtualenv is wrong — workshop_public/snowflake_migration_lab/01-setup-snowflake/ or workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/ — then delete and rebuild it against the pinned interpreter, for example rm -rf .venv && python3.13 -m venv .venv && source .venv/bin/activate, and reinstall that venv's adapter as shown in the learner page's Step 4.
• No teardown script applies to this module — nothing is provisioned in either cloud yet. If a partner needs to redo a step, it is cheaper to just rerun it than to reset anything.
• TODO: confirm during rehearsal whether distributing a pre-built venv ahead of time is worth it for a room with unreliable Wi-Fi, instead of live-installing five tools and two venvs on the day.