Aísla cada proyecto en su propio venv, fija las versiones de las dependencias y adopta una estructura de proyecto reproducible.
Abrir esta lección en KodokonInstalar las dependencias de todos tus proyectos en el mismo intérprete lleva directo a un conflicto de versiones: el proyecto A necesita requests 2.31, el proyecto B una versión incompatible. El entorno virtual (venv) aísla cada proyecto: su intérprete, su pip, sus paquetes. Es la práctica profesional no negociable - un proyecto, un entorno, recreable de forma idéntica en cualquier máquina.
python -m venv .venv
source .venv/bin/activate
# On Windows:
# .venv\Scripts\activate
python -m pip install requests
python -m pip listPara que la instalación sea reproducible, fija las versiones. pip freeze exporta el entorno entero, dependencias transitivas incluidas, con versiones exactas: máxima reproducibilidad, actualizaciones laboriosas. El enfoque moderno separa las dos necesidades: las dependencias directas declaradas en pyproject.toml con restricciones flexibles, y un archivo de bloqueo generado para la instalación exacta. A la escala de un proyecto pequeño, requirements.txt sigue siendo perfectamente respetable.
python -m pip freeze > requirements.txt
# On another machine:
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txtEn cuanto a la estructura, el src layout es la referencia: el código vive en src/<package>/, las pruebas en tests/, la configuración en pyproject.toml. El sentido de la carpeta src no es estético: impide importar por accidente el paquete local desde el directorio actual, lo que ocultaría errores de empaquetado - tus pruebas se ejecutan contra el paquete realmente instalado. Durante el desarrollo, pip install -e . instala el proyecto en modo editable.
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