Isolez chaque projet dans son venv, figez les dépendances et adoptez une structure de projet reproductible.
Ouvrir cette leçon dans KodokonInstaller les dépendances de tous vos projets dans le même interpréteur mène droit au conflit de versions : le projet A exige requests en 2.31, le projet B une version incompatible. L'environnement virtuel (venv) isole chaque projet : son interpréteur, son pip, ses paquets. C'est la pratique professionnelle non négociable - un projet, un environnement, recréable à l'identique sur n'importe quelle machine.
python -m venv .venv
source .venv/bin/activate
# Sous Windows :
# .venv\Scripts\activate
python -m pip install requests
python -m pip listPour rendre l'installation reproductible, figez les versions. pip freeze exporte tout l'environnement, dépendances transitives comprises, avec des versions exactes : reproductibilité maximale, mises à jour laborieuses. L'approche moderne sépare les deux besoins : les dépendances directes déclarées dans pyproject.toml avec des contraintes souples, et un fichier de verrouillage généré pour l'installation exacte. À l'échelle d'un petit projet, requirements.txt reste parfaitement honorable.
python -m pip freeze > requirements.txt
# Sur une autre machine :
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txtCôté structure, le src layout fait référence : le code vit dans src/<package>/, les tests dans tests/, la configuration dans pyproject.toml. L'intérêt du dossier src n'est pas cosmétique : il empêche d'importer accidentellement le paquet local depuis le répertoire courant, ce qui masquerait des erreurs de packaging - vos tests s'exécutent contre le paquet réellement installé. Pendant le développement, pip install -e . installe le projet en mode éditable.
mkdir -p src/billing tests
touch src/billing/__init__.py
touch src/billing/invoices.py
touch tests/test_invoices.py
touch pyproject.toml README.md .gitignore
echo ".venv/" >> .gitignore