venv en WSL vs Local

Desde hace medio año he estado integrando cada vez más proyectos en Django. Lo que al principio fue una simple curiosidad se ha convertido en una herramienta muy práctica para segmentar la lógica de las funciones y monitorizar el flujo de datos. Además, el uso de arquitecturas REST resulta muy útil para el monitoreo del flujo de información. Sin embargo, nada es perfecto, y es aquí donde entra en juego la correcta conexión y manejo de la información.

Diagrama comparativo de entornos virtuales en WSL versus entorno local — Diagrama comparativo: Uso de un venv en WSL versus fuera de él.

Uso de SQLite en Django

Django incluye, por defecto, la base de datos SQLite (db.sqlite3), la cual es muy adecuada para proyectos pequeños, ya que cuenta con un gestor integrado sencillo de configurar y manejar. Sin embargo, cuando el proyecto crece, SQLite deja de ser una opción recomendada, ya que:

Concurrencia limitada: No es eficiente en operaciones simultáneas.
Escalabilidad: No está diseñada para cargas intensivas de trabajo.
Características avanzadas: Carece de funcionalidades de consulta complejas que ofrecen otros sistemas de gestión de bases de datos, como PostgreSQL o MySQL.

Entornos Virtuales en Django

Aquí es donde entra en juego el actor principal de esta charla: los entornos virtuales de trabajo. Django utiliza un entorno virtual porque se basa en Python, lo que permite gestionar de forma aislada las dependencias y configuraciones de cada proyecto. Es recomendable generar un entorno virtual específico para cada proyecto.

Las formas de crearlo varían según el sistema operativo (Linux, Windows o macOS) y el IDE que se emplee; por practicidad, yo he optado por Visual Studio Code.

Dentro de mi flujo de trabajo, utilizo principalmente WSL junto con una terminal zsh y otra terminal bash para Git, que se han convertido en mis compañeros de trabajo imprescindibles. Sin embargo, surge un conflicto: cuando el proyecto se encuentra directamente en la sesión remota de WSL, la comunicación con una base de datos ubicada en Windows requiere pasos adicionales.

Creación y Activación de un Entorno Virtual en VS Code

Una vez que tienes WSL y una distribución de Linux instalada, sigue estos pasos para crear y activar un entorno virtual en tu carpeta de proyecto:

Crear el entorno virtual:
Navega a la carpeta de tu proyecto y ejecuta:
```
python3 -m venv nombre_de_tu_venv
```
Activar el entorno virtual:
Ejecuta el siguiente comando:
```
source nombre_de_tu_venv/bin/activate
```
Verificar la activación:
Usa:
```
which python
```
o
```
python --version
```
para confirmar que la ruta corresponde a la de tu entorno virtual.
Seleccionar el intérprete en VS Code:
Presiona Ctrl+Shift+P (o Cmd+Shift+P en macOS), elige Python: Select Interpreter y selecciona el intérprete ubicado en nombre_de_tu_venv/bin/python.

Diferencias entre Trabajar en WSL o en el Entorno Local

Existe una gran diferencia entre cargar un proyecto dentro de WSL y hacerlo en modo local. Si no se trabaja en WSL, la activación del entorno virtual y la instalación de dependencias se vuelven procesos repetitivos en cada sesión, y, dependiendo de los permisos de administrador, la instalación de requerimientos puede complicarse.

Trabajar directamente en WSL ofrece varias ventajas:

Es una forma de trabajo más segura, gracias a la segmentación entre el entorno y el sistema operativo.
En proyectos más complejos, trabajar en WSL ahorra tiempo y, al combinarlo con Docker, la migración del proyecto se convierte en una gran ventaja.

¿Cómo diferenciar si estás trabajando en WSL o no?

En Visual Studio Code aparece la indicación [WSL: Ubuntu] cuando abres una carpeta o proyecto directamente en la sesión remota de WSL mediante la extensión Remote - WSL. Esto significa que:

Cómo abres el proyecto:
- Proyecto con [WSL: Ubuntu]: Se abrió usando “Open Folder in WSL” o “Reopen in WSL”. Internamente, VS Code lanza un servidor dentro de WSL y la exploración de archivos, terminal y extensiones funcionan "desde Linux".
- Proyecto sin etiqueta: Se abrió de forma local (por ejemplo, desde C:\ o D:\), aunque se utilice una terminal WSL para ejecutar comandos; en este caso, VS Code sigue corriendo en Windows.
Ubicación del proyecto:
- Si el proyecto está en la ruta \\wsl$ o /home/usuario/... (sistema de archivos de WSL), VS Code normalmente te preguntará si deseas abrirlo en modo WSL.
- Si el proyecto está en una ruta de Windows, se considerará parte del sistema de archivos local.
Extensión Remote - WSL:
- Esta extensión hace que VS Code ejecute sus procesos internos y extensiones dentro de la distribución de Linux (Ubuntu, Debian, etc.), lo que se refleja en la etiqueta [WSL: Ubuntu].
- Si no usas esta extensión, VS Code no mostrará dicha etiqueta, incluso si inicias una terminal WSL.

Conexión de Bases de Datos con WSL

Un problema común surge al conectar una base de datos ubicada en Windows o macOS con un proyecto que se ejecuta en WSL. Al usar el puerto 3306 (por defecto en muchos gestores de bases de datos), se pueden generar conflictos al trabajar con múltiples "localhost".

Para solucionar este inconveniente, cambié la dirección de mi localhost en el gestor de la base de datos y modifiqué el puerto de salida. Esta configuración se realizó en el archivo services.py de mi proyecto. Puedes consultar la documentación de MySQL o la documentación de PostgreSQL para más detalles sobre la configuración de puertos y conexiones.

Además, un recurso que me fue de gran ayuda fue un script en Python para validar, dentro de mi entorno virtual en WSL, si la conexión con la base de datos era adecuada. Espero que este ejemplo te ahorre tiempo si te encuentras con un problema similar.

# By JLBaur | Ver documentación completa en GitHub.
import MySQLdb

	try:
		# Establish a connection to the MySQL server.
		# - 'host': The IP address of the server you discovered (e.g., the host running XAMPP).
		# - 'port': The TCP port for MySQL. If XAMPP is configured on port 3300, use 3300.
		# - 'user': The MySQL username with privileges to connect and query.
		# - 'passwd': The password for the specified user.
		db = MySQLdb.connect(
			host="172.19.0.0",     # IP you found, or localhost
			port=3306,             # For instance, "n" if XAMPP uses that port
			user="",
			passwd=""
		)
	
		print("Successfully connected to the database.")
	
		# Create a cursor object to execute queries.
		cursor = db.cursor()
	
		# Execute an SQL statement to show all available databases.
		cursor.execute("SHOW DATABASES;")
	
		# Fetch all the rows returned by the query.
		databases = cursor.fetchall()
	
		print("Available databases:")
		# Loop through each row (database name) returned
		for (db_name,) in databases:
			print(f"  - {db_name}")
	
	# Catch any MySQLdb errors (e.g., connection issues, authentication problems, etc.).
	except MySQLdb.Error as e:
		error_code, error_msg = e.args
		print(f"Error connecting: Code {error_code}, Message: {error_msg}")