Entornos virtuales de Python: común y Anaconda
Los entornos virtuales de Python nos van las siguientes ventajas:
- Aíslan la ejecución de los proyectos (poder ejecutar diferentes proyectos que trabajen con versiones tanto de Python como de cierta biblioteca/paquete diferente)
- Uso particular de entornos (virtuales) preparados (con ciertas bibliotecas/paquetes instalados); es decir, cada proyecto se ejecutará en el entorno virtual que es bueno para proyectos de cierta índole (por ejemplo, si creamos un proyecto de química, nos interesará ejecutar nuestro proyecto en un entorno que use bibliotecas/paquetes para el cálculo químico o conectarnos a servidores que obtengan información química)
- Uso exclusivo de un entorno por proyecto para un máximo aislamiento de los proyectos.
- Previene errores en la instalación de Python global (“Python común” o “base de Anaconda”); sobre todo previene la sobre-escritura no deseada de variables, métodos y clases.
- Garantiza el uso de la versión correcta de Python y de las bibliotecas/paquetes cada proyecto.
- Para los que nos gusta trabajar con la última tecnología (versión), facilita el uso de nuevas versiones de Python y bibliotecas/paquetes en proyectos nuevos (da igual que la mitad de los proyectos estén ejecutándose en una versión antigua en una máquina, trabajar con la nueva versión también funcionará en esa misma máquina y no pisará nada de la antigua versión).
- Agiliza la refactorización de código de Python antiguo al nuevo (mantenimiento), al independizar entornos se pueden realizar las pruebas por separado y cuando esté preparado realizar el cambio. Además, como no se usa la instalación global, se puede ir actualizando cada proyecto con independencia y sin afectar al resto.
- Permite crear un listado de los requisitos (dependencias de paquetes y versión de Python principalmente) para distribuir el proyecto a otra máquina (mover/copiar el proyecto a otra máquina, o pasar el proyecto a alguien), con solo copiar el proyecto que incluya el listado de requisitos ya se encargará el gestor de dependencias de preparar todo para que funcione correctamente (mediante este listado se descargarán las dependencias y lo que sea necesario automáticamente; por lo que tendremos el proyecto listo para usar en poco tiempo y sin apenas hacer nada).
Disfrutaremos de estas ventajas tras una muy breve configuración que tendremos que pensar bien antes de aplicarla. Y para esto deberemos tener claras las diferencias de los entornos de Python y del negocio (es decir, de los proyectos en los que se aplicará y el lugar, que puede ser una empresa o en casa, en un ordenador o en una granja de servidores). Para entender bien todo esto de los entornos de Python recomiendo leer previamente el artículo de Entornos de Python: común y Anaconda (base) que concebí con la idea de ser un asiento y una primera parte a este otro artículo (aunque si ya tienes bastantes años de experiencia con los entornos de Python: Anaconda y Python común desde la consola, así como PIP; entonces, te lo puedes saltar).
Aprovechando a que veremos como se utilizan los entornos virtuales con «Anaconda prompt», vamos a sacar el máximo valor a aprender a la vez a gestionar los entornos virtuales con el entorno gráfico «Anaconda Navigator» con el apartado que te he creado al final de este mismo artículo.
Nota: En este artículo voy a entrar en detalle para entender tanto el funcionamiento como el uso de los diferentes entornos virtuales en Python entre “Python común” y “Python instalado con Anaconda”. Si quieres una explicación más directa y breve de los entornos virtuales de Python te la hemos preparado en el artículo de venv (entornos virtuales) en Python.
¿Qué es un entorno virtual de Python?
Un entorno virtual de Python es una copia de un entorno de Python con la motivación de aislar un entorno de Python de otro.
En la siguiente imagen muestro como se “copiaría” (mediante la biblioteca/paquete “virtualenv” de Python) un entorno de “Python común” o un entorno base de “Python instalado con Anaconda” (en la imagen escribo “base” para representar a ambos) en diferentes entornos virtuales por separado (“venv1”, “venv2”, “venv3”). Puedes observar que tanto el intérprete de Python como la carpeta “Lib” ha sido copiada a otro directorio, por lo que si le ocurre algo a los ficheros de un entorno virtual no afectará al resto. Entonces, los scripts de Python no se ejecutarán con “base”, sino con un entorno virtual (o bien “venv1” o “venv2” o “venv3”).
Como cada entorno virtual actúa con sus ficheros por separado, varios entornos virtuales podrán tener la misma versión o diferente de Python (pero son instalaciones diferentes); y, por otro lado, pueden tener las mismas o diferentes bibliotecas (siendo carpetas diferentes).
La principal virtud de un entorno virtual es que nuestros proyectos siempre funcionen en un entorno preparado exclusivamente para dichos proyectos, en la misma máquina en la que puedan existir otros proyectos que requieran de un entorno diferente. También protegeremos nuestro proyecto de manipulaciones externas del entorno y nos aseguraremos el funcionamiento correcto.
Nota sobre la creación de entornos virtuales como “copia” del global: para facilitar la comprensión y en la anterior imagen hablo de una “copia perfecta” del entorno Python global (o base) a cada “entorno virtual de Python” y realmente no es así, no todo se copia. Hay cosas que directamente se descargan y otras que se referencian, para liberar espacio y para tardar menos tiempo al crear los entornos virtuales (por ejemplo, los paquetes incorporados de Python no se copiarán, sino que se referenciarán hacia el global/base; por lo que cuidado al hacer cambios/actualizar el global/base si hay entornos virtuales que lo usen).
Ejemplo realista para entender cuándo usar entornos virtuales
Supón que estás trabajando para una empresa que tiene miles de scripts de Python en una misma máquina (seguramente un servidor) y todos están funcionando en Python 2 que tienen instalado como “Python común”. Ahora nosotros queremos crear un script que funcione con el nuevo Python 3; si nos da por actualizar el Python de la máquina lo más seguro es que todos los scripts de la empresa dejen de funcionar, así que nos tocará programar nuestro script de Python en la antigua versión 🙁
Para evitar esto se suelen utilizar los entornos virtuales, así podremos tener un entorno virtual con Python 2 sobre el que funcionarán los scripts antiguos y uno para Python 3 para los scripts nuevos.
Pero ahora queremos instalar un paquete (una biblioteca) para nuestro proyecto y resulta que queremos utilizar la versión nueva de cierta biblioteca que incorpora un “método NUEVO” que funciona mejor que el antiguo “método VIEJO” de la anterior versión. Si actualizamos tanto la biblioteca instalada sobre el “Python común” como en un entorno virtual compartido por varios proyectos que utilicen el antiguo “método VIEJO” de la biblioteca dejarán de funcionar; debido a que el método que se llamaba “método VIEJO” habrá sido eliminado -ya que habrá sido sustituido por el que se llama “método NUEVO”- por lo que todas las referencias al “método VIEJO” darán error.
Debido a esto, en este ejemplo se puede dar otro paso más, y es tener un entorno virtual particular para cada proyecto para así tener completamente independizados todos los proyectos de Python, sin tener problemas de compatibilidades
Además, de esta manera, copiando el proyecto con su entorno virtual particular a otro ordenador, nos aseguraremos de que vaya a funcionar nuestro proyecto en cualquier máquina (luego puede haber otro tipo de problemas, pero no de entorno). Aunque en teoría esto suena bonito y es una de las ventajas, en la práctica NO hay que copiar el entorno virtual a otro ordenador, sino que copiaremos sus requisitos y lo replicaremos (lo veremos más adelante).
Nota sobre este ejemplo: Quiero dejar claro que este es un ejemplo completamente inventado (basado en experiencia personal), para entender el “para qué” de los entornos virtuales y tener el conocimiento de saber dónde aplicarlos. No hace falta que le diga a ninguna empresa como hacer su trabajo, cada una sabrá lo que es lo mejor para cada una de ellas, o si tiene que usar una cosa u otra.
Si creamos un proyecto de Python tendremos que escoger con que entorno de Python ejecutar nuestro código (en el ejemplo con: “base”, “venv1”, “venv2” o “venv3”).
Es decir, qué entorno activar, para ejecutar nuestro script de Python como hacemos normalmente desde la consola:
python mi_script.py
Tipos de entornos virtuales de Python
Distinguimos dos tipos de entornos virtuales de Python de pendiendo si aísla a (donde digo “proyecto” puede ser desde un único script de Python a un paquete con varios):
- Un conjunto de proyectos: Un entorno virtual usado por varios proyectos a la vez.
- A un único proyecto: Un entorno virtual exclusivo para un único proyecto.
Ejemplo de entornos virtuales aislando a uno o varios proyectos
Si por ejemplo tenemos un “Proyecto A” (hemos creado una carpeta en nuestro ordenador y hemos escrito uno o varios ficheros con código Python) que queremos ejecutar con el entorno virtual que hemos llamado “venv1” simplemente activaremos este entorno virtual (o ejecutaremos directamente el “python.exe” de la carpeta “venv1”) y ejecutaremos el script principal de este proyecto. Por otro lado, tenemos dos proyectos “Proyecto B” y “Proyecto C” que necesitan utilizar unas bibliotecas diferentes (por ejemplo, bibliotecas que están en beta y que podrían desestabilizar al “Proyecto A” que es crítico para nosotros), pues creamos el entorno virtual “venv2” para instalar las bibliotecas que necesitemos y estos dos proyectos (“Proyecto B” y “Proyecto C”) ejecutados por el Python de “venv2”. Ya con la dinámica de crear entornos virtuales, decidimos crear otro “venv3” exclusivo para un nuevo proyecto “Proyecto D” y así evitar problemas en el futuro.
Cada entorno virtual puede servir tanto a uno como a varios proyectos, dependerá de nuestras necesidades cuál escoger. Por ejemplo, si sabemos certeramente que un conjunto de proyectos va a necesitar usar exactamente un grupo de paquetes/bibliotecas (por ejemplo, paquetes para trabajar con Big Data) pues con un entorno virtual preparado para varios proyectos nos bastará y será más sencillo de gestionar (por ejemplo, actualizar de una sola vez un paquete que usen todos los proyectos). Sin embargo, lo ideal es que cada entorno virtual pertenezca a un único proyecto para aislarlo completamente del resto y el contra de tener que gestionar cada uno de los entornos virtuales por separado será lo que busquemos como ventaja (por ejemplo, para que una actualización en un entorno no afecte al resto de proyectos).
Cuando creemos “un entorno virtual exclusivo” para un único proyecto puede estar:
- Dentro del mismo directorio del proyecto: cuando creemos manualmente un entorno virtual para un único proyecto suele ser la opción más cómoda pues creamos dicho entorno virtual directamente dentro de la carpeta raíz del proyecto y ya está. Se suele emplear si vamos a realizar pequeños proyectos o proyectos caseros (aunque no es la opción más profesional; principalmente porque no se debe compartir/distribuir la carpeta de un entorno virtual a otras máquinas). Como el entorno virtual está dentro de mismo proyecto, por facilitar se suele llamar siempre al entorno virtual como “venv”.
- En un directorio aparte: pese a que cada entorno virtual solo será utilizado por un único proyecto, se guarda fuera del proyecto para que no pertenezca al mismo. Aunque podemos crear a mano una carpeta aparte con los entornos virtuales, suele ser engorroso el tener que acordarse de qué entorno virtual va con cuál (además, si en un futuro borramos uno proyecto que tenga un entorno virtual asociado nos tendremos que acordar de borrar también este entorno virtual, pues ya nunca más se va a usar). Esta carpeta aparte con los entornos virtuales es interesante y cómodo que lo gestione por nosotros un “gestor de paquetes” (como Anaconda que para ello creará la carpeta “envs” o Pipenv con la carpeta “virtualenvs”). Para identificar claramente qué entorno virtual corresponde a cada proyecto (como son exclusivos por proyecto; un entorno virtual corresponde a un proyecto y viceversa) se suele llamar con el nombre del mismo proyecto.
Si utilizamos un “gestor de paquetes” como Anaconda se encargará de gestionar los entornos virtuales por nosotros y va a guardar automáticamente todos los entornos virtuales dentro del directorio “envs” que está dentro de la instalación de Anaconda. Cada entorno virtual de Anaconda se podrá usar para un conjunto de proyectos o exclusivamente para uno solo, como deseemos.
En los siguientes pasos crearemos entornos virtuales con Virtualenv tanto directamente por nosotros (a mano) como mediante un sistema de gestión de paquetes (Anaconda, Pipenv, etc.). Da igual como lo creemos, tendremos un entorno global (“Python común” o “base de Anaconda”) en el que instalaremos Virtualenv mediante PIP (hoy día suelen estar instalados ambos, así que basta con entender dónde está cada cosa). Cuando creemos de alguna de las maneras (a mano o mediante un “gestor de paquetes”) un entorno virtual, se copiarán a este una serie de archivos (entre ellos la versión de Python y la carpeta “Lib”); dentro de “Lib” incluirán algunos paquetes, y uno de ellos es el mismísimo PIP. Cada PIPse encargará de guardar los paquetes/bibliotecas que descarguemos en la carpeta “Lib” en la que se encuentra; como cada PIP se ejecuta dentro del contexto de un entorno (en el global o uno virtual activo) hará referencia a la carpeta “Lib” en donde se encuentra.
Instalar viertualenv globalmente (suele venir preinstalado)
En Anaconda ya está preinstalado,no tienes que hacer nada.
Desde Python 3.3 ya está preinstalado y tampoco tendrás que hacer nada (más información en la documentación oficial https://docs.python.org/3/library/venv.html).
Si usas una versión más antigua de Python en una consola del sistema operativo con Python (y teniendo PIP instalado; tienes como se instala PIP y ejemplos de uso en https://jarroba.com/entornos-de-python-anaconda-y-comun/) puedes instalar “virtualenv” con:
pip install virtualenv
Linux: si lo pidiera será necesario instalar virtualenv con:
sudo apt install python3-venv
Crear un entorno virtual de Python
Para crear un entorno virtual de Python necesitamos dos cosas (para que queden claros los siguientes dos puntos te recomiendo que pruebes el comando de creación que está más abajo y verás que es muy sencillo viéndolo funcionar):
- Apuntar al ejecutable de Python que queremos copiar: Si tenemos varios Python instalados en el ordenador, elegiremos uno (como por ejemplo “Python2.8 común”, “Python3.9 común”, “Alguna versión de Python incluida en Anaconda” etc.); es bastante posible que queramos usar el Python apuntado por la variable de entorno “python” o “python3”, por lo que más fácil (si estás empezando con todo este mundo de los entornos virtuales, entonces usa el de la variable de entorno como en los siguientes ejemplos).
- La ruta donde queremos crear el entorno virtual de Python: Escoge un sitio en tu ordenador para guardar la carpeta con todos los archivos del Python copiados que será el entorno virtual. Si quieres crear un “entorno virtual exclusivo” apunta dentro de tu proyecto a una carpeta para crear el entorno virtual (y llámalo “venv”; los motivos de este nombre los vimos antes), por ejemplo: /ruta/a/mi/proyecto/venv; o crea una carpeta para guardar todos los entornos virtuales exclusivos que vayas a crear (llámala, por ejemplo, “mis_entornos_virtuales”); entonces, sugiero que llames a cada entorno virtual con el mismo nombre que tiene la carpeta de tu proyecto (en minúscula, sin símbolos raros y con guiones bajos en lugar de espacios) y que le añadas detrás un identificador (puede ser la fecha con la hora y el minuto de la creación) por si en el futuro quieres tener varios entornos virtuales para el mismo proyecto (por ejemplo, para hacer pruebas o como copia de seguridad antes de actualizar paquetes).
Desde una consola del sistema operativo con Python comúnescribimos el Python que queramos utilizar (por ejemplo “python” o “python3” para usar la variable de entorno del sistema, o escribimos la ruta entera donde esté instalado el Python que queramos utilizar de nuestro ordenador; en el siguiente cuadro te muestro un truco para encontrar todas las rutas a los “Pythones” instalados en tu ordenador), el parámetro “-m venv” (“-m” indicará que queremos ejecutar un módulo instalado que en este caso es “venv”), terminado con la ruta donde queremos crear el entorno virtual de Python (“mi_virtual_env” será la carpeta del directorio raíz donde se creará el entorno virtual):
python -m venv /ruta/a/mi_virtual_env
Nota si has instalado virtualenv mediante “pip install virtualenv”: puede que tengas que utilizar la manera antigua de creación con el comando “virtualenv” (donde “-p” defines el Python a utilizar por el entorno virtual):
virtualenv -p python3 /ruta/a/mi_virtual_env
Encontrar Python en el sistema
Puedes buscar el Python (o Pythons) que tengas instalado en tu sistema operativo escribiendo en el terminal de tu sistema:
Windows:
where Python
Linux y Mac:
which Python
Recuerda probar con “python3” por si la variable de entorno se llamara así en vez de solo “python”.
Desde la consola de Anaconda con el comando “conda create” creamos el entorno virtual con el parámetro “-n mi_virtual_env” (“mi_virtual_env” es el nombre del entorno virtual que quiero crear) y en para definir la versión de Python escribimos a continuación “python=VV.VV anaconda” (donde “VV.VV” es la versión de Python que queremos instalar, para ver que versiones de Python tenemos disponibles te he dejado un cuadro más adelante; recomiendo crear con la versión más alta de Python).
conda create -n mi_virtual_env python=3.8 anaconda
Estate atento ya que a mitad de la creación se nos pedirá que aceptemos las bibliotecas incorporar, para ello escribimos la letra “y” y pulsamos “Intro/Enter”
Encontrar las versiones de Python instaladas en Anaconda
Puedes buscar los Pythons desde la consola de Anaconda:
conda search python
En Anaconda nos interesa quedarnos con la versión de Python:
¿Dónde guarda Anaconda los entornos virtuales?
Anaconda guarda todos los entornos virtuales en el directorio “envs” (por eso no se pide en el comando de creación). Por ejemplo, el anterior comando (cuyo entorno virtual he llamado “mi_virtual_env”) creará el entorno virtual en el siguiente directorio:
- Windows en “C:\Users\<Usuario>\Anaconda3\envs\mi_virtual_env\”
- Linux/Mac en “/Users/<Usuario>/opt/anaconda3/envs/mi_virtual_env\”
Puedes ver todos los entornos virtuales gestionados por Anaconda con el comando:
conda env list
O con:
conda info --envs
Verás todos los entornos virtuales creados junto a cada una de las rutas (y un asterisco “*” que marca el entorno virtual activo en esta consola):
Activar un entorno virtual de Python
Desde una consola del sistema operativo con Python común (“mi_virtual_env” es la ruta hasta el directorio raíz del entorno virtual):
Windows (el fichero de activación “activate.bat” para CMD o “activate.ps1” para PowerShell con permisos, están en la carpeta “Script” de donde se ha creado el entorno virtual, ambos se pueden activar simplemente con):
mi_virtual_env\Scripts\activate
Linux/Mac (el fichero bash de activación “activate” está en la carpeta “bin” de donde se ha creado el entorno virtual, se pueden activar simplemente con):
source mi_virtual_env/bin/activate
Desde la consola de Anaconda (“mi_virtual_env” es el nombre del entorno virtual):
activate mi_virtual_env
Nota sobre los comandos de virtualenv en Linux/Mac: puede que tengas que escribir el comando “source” delante siempre (al menos en Ubuntu solo lo he necesitado para activar, para el resto he podido evitar escribir el comando “source”). Por ejemplo:
source activate mi_virtual_env
Aparecerá a la izquierda del nombre de la ruta de la consola el nombre del entorno virtual de Python activado entre paréntesis. Si por ejemplo activo el entorno virtual que yo he llamado “mi_virtual_env” se verá algo así:
Desde este momento, al utilizar Python de “manera normal”, con el comando de ejemplo:
python mi_script.py
Se utilizará el Python y los paquetes de Libs del entorno virtual activado (por tanto, se utilizará el PIP guardado en esta carpeta Lib y que apuntará a esta misma carpeta para instalar otros paquetes que queramos).
Nota sobre Anaconda Navigator: En un cuadro más adelante explico como “gestionar los entornos virtuales desde Anadonda Navigator” (es el interfaz gráfico, no confundir con “Anaconda Prompt” que es la consola que hemos estado utilizando hasta ahora).
Desactivar un entorno virtual de Python
Para desactivar un entorno virtual hay que escribir el siguiente comando desde una consola del sistema operativo o desde la consola de Anaconda (que tenga un entorno virtual activo):
deactivate
Y aunque el anterior funciona, en Anaconda es más recomendable usar:
conda deactivate
Al desactivar el entorno virtual, si se utilizara Python en un futuro hay que tener en cuenta que:
- En la consola del sistema se utilizará el “Python común”.
- En la consola de Anaconda se utilizará “(base)”, que es el Python instalado en Anaconda.
Nota sobre cerrar la consola: Si cierras una consola también se desactiva el entorno virtual (realmente la activación se realiza en memoria y no se guarda el estado entre instancias de la consola). Si se vuelve a abrir la consola o se abre otra aparte, si se desea activar el entorno virtual habrá que activarlo.
Eliminar un entorno virtual de Python
En Python común simplemente elimina la carpeta que se ha creado con el entorno y ya está.
Windows: botón derecho sobre la carpeta (que yo he llamado “mi_virtual_env”) y eliminar.
Linux/Mac: Eliminar la carpeta (que yo he llamado “mi_virtual_env”):
rm -rf mi_virtual_env
Anaconda, como es un gestor de paquetes, tiene su propio comando que lo hace por nosotros (te preguntará si estás seguro de eliminar el entorno virtual, para confirmar escribe “y” y pulsa “Intro/Enter”):
conda remove --name mi_virtual_env --all
Probar nuestro entorno virtual de Python
Como hemos visto antes, activamos nuestro entorno virtual. Sabremos que está activo, pues en mi caso aparece a la izquierda entre paréntesis el nombre con el entorno virtual activo, en mi caso: (mi_virtual_env)
Da igual donde lo hagamos, tanto en la consola del sistema con “Python común” como con la consola de Anaconda, los siguientes pasos funcionan exactamente igual.
Para probar vamos a instalar mediante el gestor de paquetes PIP (tienes como se instala PIP y ejemplos de uso en https://jarroba.com/entornos-de-python-anaconda-y-comun/) algún paquete que queramos, que va a quedar guardado en la carpeta “Lib” del entorno virtual (sin ensuciar el resto, y cuando eliminemos el entorno virtual también lo harán los paquetes que tenga instalados).
Nota: Antes de continuar, quiero indicarte que es igual a cualquier otra instalación de paquetes de Python con PIP; lo único “espacial” es que debemos tener activo un entorno virtual para poder usar los paquetes instalados en dicho entorno (y asegurarnos dónde se van a instalar los nuevos paquetes, para no equivocarnos de entorno).
Como estamos trabajando con el entorno virtual, primero vamos a consultar que paquetes/bibliotecas hay instaladas dentro de este entorno virtual con el comando de PIP:
pip list --local
Verás todos los paquetes que se han copiado a tu entorno virtual y los que tendrás disponibles ¿Qué quieres más paquetes? para eso vamos a instalar alguno ahora mismo 😉
Para este ejemplo voy a instalar el paquete “sorted-in-disk” (es un desarrollo de código libre que hice para ordenar enormes cantidades de datos en disco, pues “sorted” de Python está limitado a la memoria RAM y tantos datos no caben ahí, más información en https://pypi.org/project/sorted-in-disk/; para probar puedes instalar el paquete que quieras):
pip install sorted-in-disk
Este y sus dependencias se instalarán:
Volvemos a consultar las bibliotecas instaladas en el entorno virtual:
pip list --local
Y podemos probar que efectivamente nos encuentra la biblioteca si abrimos el intérprete de Python escribiendo:
python
E importamos la biblioteca:
from sorted_in_disk import sorted_in_disk
Si no da ningún error al importar es que funciona correctamente. Aunque si queremos podemos probarla y al terminar salir de la consola interactiva de Python escribiendo “exit()”, por ejemplo con:
print(list(sorted_in_disk(["B", "A"])))
exit()
Ahora desactivamos el entorno virtual:
deactivate
Si buscamos el paquete/biblioteca que acabamos de instalar en el entorno virtual en el “Python común” o “(base)” en Anaconda no lo encontraremos:
pip list --local
Y si volvemos a la consola interactiva de Python (escribiendo “python” en la consola) y probamos a importar el paquete que instalamos en el entorno virtual.
from sorted_in_disk import sorted_in_disk
Nos dará un error que nos dice que no existe.
Gestionar los entornos virtuales desde Anaconda Navigator (tutorial rápido de Anaconda Navigator)
Lo que hemos hecho por la consola de Anaconda se puede hacer en gran medida desde la interfaz gráfica del Anaconda Navigator.
Abrimos Anaconda Navigator (teniendo instalado Anaconda como se explicó previamente, busca en el buscador de tu sistema operativo “Anaconda Navigator”).
“Anaconda Navigator” nos mostrarán una serie de pestañas a la izquierda y el contenido de dicha pestaña a la derecha. Nada más entrar en “Anaconda Navigator” estaremos en la pestaña “Home” que tiene a la derecha varios IDEs preinstalados y que podremos utilizar. Aunque no voy a detallar cada IDE, indicarte que para Python trae pre-instaldos: JupiterLab, Notebook, Spyder, VS Code o PyCharm (algunos se instalan con el primer uso y podrían variar los IDEs con el tiempo). Sobre los IDEs no nos preocupamos por ahora, pruébalos en un futuro y si quieres más información sobre algunos tiene vídeos explicativos en https://jarroba.com/curso-de-python-0-entorno-de-desarrollo-para-python/
Vamos a la pestaña de la izquierda llamada “Environments”. Esta pestaña “Environments” estarán todos los entornos virtuales que creemos y que se guardarán en la carpeta “envs” (salvo “base” y “rstudio”; que son los Python base para los lenguajes de programación Python y R respectivamente).
Para crear un nuevo entorno virtual pulsamos abajo en “Create”, le ponemos un nombre (por ejemplo, yo le he puesto “mi_virtual_env”), elegimos una versión de Python y pulsamos el botón de “Create”.
Con esto ya tendremos nuestro entorno virtual de Python creado y listo para ser usado.
Si seleccionamos nuestro entorno virtual lo seleccionamos veremos a la derecha los paquetes (bibliotecas en el directorio “Lib” del entorno virtual) que tiene instalado nuestro entorno virtual (aquí también la podremos gestionar).
Para abrir una consola de Anaconda con el entorno virtual que queramos, primero lo seleccionamos en el listado de la pestaña “Environments” y pulsamos en la flecha verde que está junto al nombre, en el desplegable pulsando en “Open Terminal” se abrirá un nuevo terminal/consola con este entorno virtual activo y listo para ser usado.
Si queremos eliminar algún entorno virtual desde aquí, si lo seleccionamos y pulsamos el botón de “Remove” para eliminarlo.
compartir/distribuir un entorno virtual
El entorno virtual como tal (sus ejecutables, carpetas y ficheros) no se debe compartir o distribuir, ya que no asegurará un correcto funcionamiento en otro ordenador/servidor diferente al que se creó (en la carpeta virtual puede que se creen configuraciones y ficheros que solo funcionen en el ordenador donde se creó en concreto).
Mejor crear un fichero de requisitos (como veremos más adelante) y copiarlo a la otra máquina con un entorno virtual nuevo; y si quieres que esto sea todavía más fácil, te explico cómo usar Pipenv para compartir/distribuir entornos virtuales de una manera correcta en un artículo dedicado a Pipenv como gestor de entornos virtuales de Python.
Por tanto, la carpeta de un entorno virtual no se debe subir al repositorio (Git o cualquier otro). Solo se debe subir al repositorio el proyecto y los requisitos del entorno virtual (veremos cómo se hace esto más adelante y en el artículo sobre Pipenv). Por ejemplo, si tienes creado un entorno virtual exclusivo y lo has creado dentro del mismo proyecto, si utilizas Git añade al “.gitignore” la carpeta y todas sus subcarpetas de la carpeta del entorno virtual para excluirlos.
Una buena práctica es crear los “entornos virtuales exclusivos por proyecto” en una carpeta fuera de los proyectos (es decir, por un lado, podríamos tener una carpeta “entornos_virtuales” y, por otro lado, “proyectos_python”) y así no tener que preocuparnos de ensuciar el proyecto y de excluir ficheros a compartir (además, de que se comparte todo lo necesario para hacer funcionar al proyecto en otra máquina). Por el contrario, crear el entorno virtual a mano fuera del proyecto implica que tendrás que acordarte de que existe esa carpeta que es propia de tal proyecto en concreto, para si borras el proyecto acordarte de borrar la carpeta con el entorno virtual también (para evitar tener que hacer a mano esto se utiliza Pipenv que explico en su propio artículo); ya que si no te acuerdas de borrar le entorno virtual tendrás ficheros basura ocupando espacio (sin el proyecto, un “entorno virtual exclusivo” no sirve para nada).
Copiar un entorno (virtual) de una máquina a otra a mano
Para copiar un entorno (sea virtual o global) de una máquina (ordenador/servidor) a otra manualmente simplemente abre la consola con el entorno (activa el entorno virtual si es necesario). Y con el comando de PIP exporta todos los requisitos a un archivo:
pip freeze > requisitos.txt
Copia ese archivo “requisitos.txt” a la otra máquina.
Crea un nuevo entorno en la nueva máquina (global, o preferiblemente virtual); si es virtual activa este nuevo entorno de la otra máquina y ejecuta:
pip install -r requisitos.txt
Se habrán instalado los mismos requisitos que en la otra máquina.