00 Préparation

Complément formateur du module participant 00 Préparation.

Durée

Environ 30 minutes au total. Il s’agit d’un travail préalable, pas d’un contenu à réaliser le jour J : envoyez-le aux partenaires avant la session et vérifiez son achèvement la veille, et non le matin même. Aucune partie ne s’exécute de façon autonome au sens de « lancer puis s’absenter » : cinq outils doivent être installés, deux comptes créés, un dépôt cloné et deux environnements virtuels construits, toujours avec le partenaire au clavier. Un partenaire qui arrive sans l’avoir fait nécessite environ 30 minutes de rattrapage en direct, au détriment du contenu prévu pour le module 01.

Fil conducteur

• Présentez ce module comme de la plomberie, et non comme du contenu : deux clouds (Snowflake comme source, ClickHouse Cloud comme cible), deux adaptateurs dbt, un par cloud, avec la même contrainte stricte sur la version minimale de Python.
• Répétez, plus d’une fois, le fait essentiel : dbt-snowflake et dbt-clickhouse exigent tous deux Python 3.11, 3.12 ou 3.13. Python 3.14 et les versions ultérieures cassent une dépendance transitive commune, mashumaro, dans les deux adaptateurs.
• Montrez les deux environnements virtuels distincts — workshop_public/snowflake_migration_lab/01-setup-snowflake/.venv et workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/.venv — puis expliquez pourquoi ils ne peuvent pas être réunis : les deux adaptateurs imposent des plages de versions incompatibles pour certaines dépendances.
• Encouragez la création des deux comptes cloud dès maintenant, et non le jour de la session : ni l’essai Snowflake ni l’essai ClickHouse Cloud ne doivent bloquer le début du module 01.

Erreurs courantes

• Python 3.14 et les versions ultérieures cassent dbt-snowflake et dbt-clickhouse à cause de mashumaro. C’est l’erreur principale de ce module et la plus dangereuse, car un interpréteur mal choisi ne provoque pas d’échec ici : le problème apparaît deux modules plus tard sous la forme d’une erreur d’import dbt déroutante, sans lien apparent avec la version de Python. Vérifiez que python3 --version indique 3.11, 3.12 ou 3.13 pour l’interpréteur réellement employé par chacun des environnements — workshop_public/snowflake_migration_lab/01-setup-snowflake/.venv et workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/.venv — et pas seulement pour l’interpréteur système, avant de valider ce module pour un partenaire.
• À FAIRE : aucune autre panne propre à ce module n’est documentée dans le README du laboratoire. Ajoutez ici tout problème observé lors des répétitions (proxy ou pare-feu d’entreprise bloquant pip install ou terraform init, demande de licence Docker Desktop au premier lancement, délai d’approbation des comptes d’essai).

Étapes de réinitialisation

• Mauvaise version de Python dans un environnement : placez-vous avec cd dans le module concerné — workshop_public/snowflake_migration_lab/01-setup-snowflake/ ou workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/ —, puis supprimez et recréez l’environnement avec l’interpréteur imposé, par exemple rm -rf .venv && python3.13 -m venv .venv && source .venv/bin/activate, avant de réinstaller l’adaptateur propre à cet environnement comme indiqué à l’étape 4 de la page participant.
• Aucun script de suppression ne concerne ce module : rien n’est encore provisionné dans les deux clouds. Si un partenaire doit recommencer une étape, la relancer coûte moins cher que de réinitialiser quoi que ce soit.
• À FAIRE : confirmez pendant la répétition s’il vaut mieux distribuer à l’avance un environnement virtuel préconstruit lorsque le Wi-Fi est peu fiable, plutôt que d’installer en direct cinq outils et deux environnements le jour même.