Anaconda Distribution

Presentación

Quieres probar pandas.

Después NumPy.

Después Jupyter.

Después scikit-learn.

Un package necesita una biblioteca nativa.

Otro quiere una versión diferente de Python.

El tercero funciona perfectamente.

Siempre que, evidentemente, no vuelvas a tocar absolutamente nada.

Es exactamente el tipo de situación al que Anaconda Distribution intenta responder.

Su idea no es sustituir Python.

Consiste más bien en proporcionar un entorno Python ya preparado para aquellos ámbitos en los que las dependencias se vuelven rápidamente más complicadas que el simple archivo .py que queríamos escribir al principio.

Python, pero con el taller ya instalado

Instalar Python desde python.org proporciona esencialmente el lenguaje, su biblioteca estándar y las herramientas fundamentales.

Anaconda Distribution adopta una filosofía diferente.

Incluye, entre otras cosas:

Python, el lenguaje;

conda, para gestionar packages y entornos;

Anaconda Navigator, una interfaz gráfica para trabajar con esos entornos;

Jupyter Notebook y JupyterLab, para la exploración interactiva;

además de un importante conjunto de bibliotecas destinadas a data science, cálculo científico, visualización y machine learning.

NumPy.

pandas.

SciPy.

Matplotlib.

Jupyter.

scikit-learn.

Y muchas otras.

La idea es sencilla:

en lugar de construir progresivamente un entorno científico, Anaconda proporciona directamente un taller ya equipado.

Eso significa más espacio ocupado en disco.

Pero también muchas menos pequeñas decisiones que tomar antes de empezar.

Anaconda no es Python

Esta distinción es esencial.

Python es el lenguaje.

Anaconda Distribution es una distribución que incluye Python y construye todo un entorno a su alrededor.

Se puede utilizar perfectamente Python sin Anaconda.

Con venv y pip.

Con uv.

Con Poetry.

Con conda instalado de otra manera.

Con Miniconda.

Con Miniforge.

O con muchos otros workflows.

A la inversa, Anaconda utiliza Python como pieza central, pero añade una lógica de gestión de packages que va más allá del ecosistema Python por sí solo.

Aquí es donde conda se vuelve importante.

Conda: la verdadera mecánica bajo el capó

Conda es al mismo tiempo un gestor de packages y un gestor de entornos.

Es open source y funciona en Windows, macOS y Linux.

Su interés particular es que no se limita a los packages de Python.

Un package conda puede incluir:

bibliotecas del sistema, ejecutables, módulos Python o R, dependencias nativas y otros componentes necesarios para ejecutar un software.

Esto resulta especialmente interesante en cálculo científico.

Instalar una biblioteca Python pura suele ser relativamente sencillo.

Instalar una biblioteca que depende de BLAS, LAPACK, CUDA, compiladores, bibliotecas C/C++ u otros componentes nativos puede resultar mucho más delicado.

Conda intenta gestionar todo ese conjunto como un único grafo de dependencias.

Es una de las razones por las que Anaconda se ha instalado tan profundamente en la data science.

Distribution, conda y Miniconda: tres cosas diferentes

El vocabulario puede volverse confuso rápidamente.

Esta distinción evita muchos malentendidos.

Se puede querer conda sin querer toda Anaconda Distribution.

Precisamente por eso Miniconda y Miniforge se han vuelto populares.

Anaconda Distribution apuesta por la comodidad de «muchas cosas ya instaladas».

Miniconda apuesta más bien por:

«dame el motor, ya instalaré después lo que necesite».

Un producto que se ha vuelto más amplio que un simple instalador de Python

Anaconda ha evolucionado mucho.

La Distribution desktop sigue siendo una pieza importante, pero ahora vive dentro de una plataforma más amplia que incluye, entre otras cosas, notebooks cloud, servicios de packages, herramientas de colaboración, Anaconda Assistant, funciones de seguridad y ofertas destinadas a empresas.

Los planes actuales se reparten entre Free, Starter y Business.

Esta evolución cambia la manera de presentar Anaconda.

Históricamente, muchos desarrolladores la conocieron como:

«el gran instalador de Python para data science».

Hoy, Anaconda intenta convertirse cada vez más en una plataforma de desarrollo y gobernanza alrededor de Python, los datos y la IA.

Sin embargo, la Distribution sigue siendo su puerta de entrada más reconocible.

Funcionalidades

Entornos aislados para cada proyecto

El principio de los entornos conda es parecido al de los entornos virtuales de Python, pero su alcance es mayor.

Se puede crear:

```bash id="8v2uy0" conda create --name analisis python=3.14

Después, otro entorno:

```bash id="qv6xby"
conda create --name proyecto-antiguo python=3.11

Ambos pueden convivir en la misma máquina.

Cada uno posee sus packages.

Su versión de Python.

Sus dependencias.

Sus bibliotecas nativas.

Después se puede pasar de uno a otro con:

```bash id="5b0i5l" conda activate analisis

Es especialmente útil cuando varios proyectos no están de acuerdo sobre la definición exacta de la palabra «compatible».

Algo que ocurre con sorprendente frecuencia.

### Instalar varias capas de dependencias en una sola operación

Con conda:

```bash id="bgfzb3"
conda install numpy pandas scipy

El gestor busca versiones compatibles entre sí y con el entorno actual.

También tiene en cuenta las dependencias relacionadas con la plataforma.

El interés se vuelve especialmente visible cuando un package depende de componentes que no proceden exclusivamente de Python.

Mientras que pip trabaja principalmente dentro del ecosistema de distribuciones Python, conda puede gestionar un conjunto de software más amplio.

Es una diferencia importante.

También explica por qué elegir entre pip y conda no debería tratarse siempre como un partido de fútbol.

No resuelven exactamente el mismo problema.

Anaconda Navigator: conda sin vivir en el terminal

No todo el mundo quiere empezar a explorar Python con:

```bash id="voz6y9" conda env list

**Anaconda Navigator** proporciona una interfaz gráfica para gestionar parte del entorno.

Permite, entre otras cosas:

crear y seleccionar entornos;

buscar e instalar packages;

actualizar determinados componentes;

iniciar aplicaciones como JupyterLab;

abrir herramientas asociadas a distintos entornos.

Navigator hace Anaconda especialmente accesible para quienes empiezan en data science o con notebooks.

Permite ver los entornos y los packages como objetos manipulables en lugar de como una sucesión de comandos.

No es imprescindible.

Pero para algunos usuarios, es precisamente lo que convierte la gestión de dependencias en algo menos abstracto.

### Jupyter integrado en el entorno

Anaconda Distribution incluye el ecosistema Jupyter.

Un notebook permite mezclar:

código;

resultados;

texto;

ecuaciones;

visualizaciones;

exploración interactiva.

Esta manera de trabajar encaja especialmente bien con la data science y la investigación.

Se cargan algunos datos.

Se ejecuta una celda.

Se observa el resultado.

Se modifica.

Se genera un gráfico.

Se vuelve a empezar.

El entorno se parece menos a un programa lineal y más a un **cuaderno de experimentación ejecutable**.

Anaconda no creó, evidentemente, Jupyter.

Pero integrarlo directamente en la Distribution reduce considerablemente la distancia entre la instalación y el primer notebook utilizable.

### Packages científicos preensamblados

La Distribution proporciona un gran conjunto de packages probados para funcionar juntos.

Incluye bibliotecas destinadas a:

análisis de datos;

cálculo numérico;

visualización;

estadística;

machine learning;

procesamiento del lenguaje;

notebooks;

herramientas científicas.

El metapackage Anaconda publicado en los channels oficiales supera hoy los **400 packages** en determinadas configuraciones.

El repositorio Anaconda da acceso a varios miles de packages adicionales.

El verdadero beneficio no es, por tanto, solamente la cantidad.

Es el trabajo realizado alrededor de su construcción, sus dependencias y su disponibilidad en varias plataformas.

### Channels: varias fuentes para los packages

Conda organiza los repositories en forma de **channels**.

Los channels `defaults` apuntan, entre otras cosas, a los repositorios gestionados por Anaconda.

Pero existen otras fuentes.

La más conocida probablemente sea **conda-forge**.

Este proyecto comunitario construye y distribuye una enorme colección de packages conda.

Se puede instalar desde un channel concreto:

```bash id="2q7wzi"
conda install --channel conda-forge package

Esta libertad es fundamental.

Utilizar conda no significa necesariamente utilizar únicamente packages construidos por Anaconda.

Y es precisamente aquí donde la distinción entre conda, Anaconda Distribution y los repositories Anaconda se vuelve esencial.

Exportar y reproducir un entorno

Un entorno que funciona en una máquina es útil.

Un entorno que puede reconstruirse en otra lo es todavía más.

Conda permite exportar información sobre las dependencias de un entorno, especialmente hacia archivos YAML.

Después se puede crear un entorno a partir de una especificación:

bash id="p6pgfw" conda env create --file environment.yml

Esto facilita:

compartir entre colaboradores;

reconstruir un entorno;

pasar a otra máquina;

determinados workflows CI/CD;

documentar las dependencias.

Pero la reproducibilidad perfecta tiene sus sutilezas.

Los packages pueden depender de la plataforma o de la arquitectura.

Un entorno exportado desde Linux x86-64 no es necesariamente una receta universal perfectamente idéntica para macOS ARM.

El archivo de entorno ayuda.

No es una máquina para viajar entre sistemas sin consecuencias.

Python no es lo único que conda sabe gestionar

Conda fue creado alrededor de Python, pero su modelo de packages no está limitado a él.

Puede distribuir elementos relacionados con:

R;

C;

C++;

Fortran;

Java;

o distintos ejecutables y bibliotecas del sistema.

Para un científico o un ingeniero, esta característica puede ser mucho más importante de lo que parece.

El notebook está escrito en Python.

Pero la pila que permite ejecutarlo puede atravesar varios lenguajes antes de llegar al procesador.

Anaconda intenta convertir todo eso en una instalación coherente.

Una base adaptada a GPU y cálculo científico

Los entornos de machine learning suelen implicar:

framework;

versión de Python;

bibliotecas del sistema;

runtime GPU;

drivers;

CUDA;

packages adicionales.

Anaconda no puede resolverlo todo automáticamente — especialmente los propios drivers del sistema.

Pero conda puede simplificar una parte importante de la pila de software.

Históricamente, es una de las razones de su popularidad para PyTorch, TensorFlow, RAPIDS y muchos entornos científicos.

Cuando la aplicación depende de numerosos componentes compilados, el peso adicional de conda puede convertirse en una ventaja en lugar de un defecto.

Casos de uso

Empezar en data science sin construir todo el entorno por tu cuenta

Quieres seguir un curso.

Pide Python.

NumPy.

pandas.

Jupyter.

Matplotlib.

scikit-learn.

El tutorial empieza dentro de seis minutos.

Probablemente no sea el momento ideal para descubrir las sutilezas de wheels, ABI, compiladores y entornos virtuales.

Anaconda Distribution ofrece un atajo.

Instalar.

Abrir Navigator o el terminal.

Abrir Jupyter.

Empezar.

Para aprender, esta sencillez sigue siendo uno de sus mejores argumentos.

Separar varios proyectos científicos incompatibles

Un proyecto antiguo depende de Python 3.10.

El nuevo utiliza Python 3.14.

Una herramienta interna exige una versión concreta de NumPy.

Un experimento quiere las versiones más recientes disponibles.

Crear varios entornos conda permite mantener esos proyectos uno al lado del otro sin pedirle a una única instalación global que resuelva todas sus contradicciones.

Cada proyecto recupera su pequeño universo.

Nadie habla con los vecinos.

La paz queda preservada.

Preparar un entorno de machine learning

Quieres probar un notebook con PyTorch, pandas, JupyterLab y varias bibliotecas científicas.

El proyecto también utiliza dependencias compiladas.

Es exactamente el terreno histórico de Anaconda.

Un entorno dedicado puede contener las versiones necesarias sin contaminar el resto del sistema.

Si un experimento se vuelve inutilizable:

se elimina el entorno.

Se empieza de nuevo.

Es infinitamente más agradable que descubrir seis meses después por qué modificar NumPy en el Python global destruyó tres proyectos que no habían pedido nada.

Dar el mismo punto de partida a un equipo o una formación

Una formación reúne a veinte personas.

Windows.

macOS.

Linux.

Distintos niveles técnicos.

El objetivo del curso es analizar datos.

No dedicar la primera mañana a:

«¿Por qué pip no encuentra esta biblioteca en tu ordenador?»

Una distribución preensamblada puede reducir mucho esta fricción inicial.

En un contexto profesional, las herramientas de gestión, repositorios privados y funciones de seguridad de los planes superiores pueden llevar esta lógica todavía más lejos.

Trabajar con bibliotecas difíciles de compilar localmente

Algunos packages Python dependen de código nativo.

Si existe una wheel compatible, pip puede ser perfectamente sencillo.

Si no existe, la historia puede ponerse más deportiva.

Compilador.

Headers.

Biblioteca del sistema.

Versiones.

Flags.

Y de repente ese pequeño pip install empieza a parecer un rito iniciático.

Los packages conda están diseñados para incluir una mayor parte de estas dependencias.

En entornos científicos y técnicos, esto puede evitar una cantidad nada despreciable de bricolaje local.

Utilizar Python sin querer aprender inmediatamente toda su fontanería

Anaconda se recomienda a menudo a principiantes porque reduce el número de conceptos necesarios al principio.

No hace falta comprender inmediatamente:

dónde se encuentra Python;

qué pip corresponde a qué entorno;

cómo instalar Jupyter;

cómo crear un entorno;

dónde está la biblioteca compilada que falta.

Se puede aprender progresivamente.

Esta simplificación tiene, sin embargo, un precio: algunas personas utilizan Anaconda durante años sin comprender realmente qué pertenece a Python, conda, Navigator o Jupyter.

La comodidad puede ocultar la arquitectura.

No es dramático.

Pero llega un momento en el que conocer las capas resulta útil.

Opinión de PANACHES

Anaconda resuelve un problema muy real.

Python es fácil de instalar.

Una pila científica Python completa y coherente, bastante menos sistemáticamente.

Son dos problemas diferentes.

Anaconda se impuso construyendo un puente entre ambos.

Su fuerza: convertir un entorno complejo en algo cotidiano

NumPy.

SciPy.

Jupyter.

pandas.

Bibliotecas nativas.

Versiones de Python.

Dependencias.

Entornos.

Todo esto puede instalarse por separado.

Y hoy, las herramientas modernas de Python hacen que esta operación sea mucho más sencilla que hace diez años.

Pero Anaconda sigue teniendo una cualidad importante:

transforma una pila científica relativamente compleja en un entorno casi ordinario.

Crear.

Activar.

Instalar.

Abrir el notebook.

Continuar.

En los ámbitos donde las dependencias nativas son numerosas, esa normalidad posee un valor real.

Pero el ecosistema Python ha cambiado mucho a su alrededor

Hace algunos años, la recomendación «instala Anaconda» era casi automática en muchos tutoriales de data science.

Hoy, el panorama es más matizado.

venv y pip han mejorado.

Las wheels están mucho más extendidas.

pyproject.toml ha estructurado el packaging moderno.

uv ha acelerado y simplificado radicalmente muchos workflows Python.

Miniforge ofrece una puerta de entrada más mínima hacia conda y conda-forge.

micromamba propone otro enfoque.

Los contenedores son habituales en entornos de producción.

Por tanto, Anaconda ya no es necesariamente la opción por defecto para cada desarrollador Python.

Y eso es algo bueno.

Una herramienta no necesita ser universal para seguir siendo excelente en su ámbito.

¿Anaconda Distribution o Miniconda?

Probablemente sea la pregunta más práctica.

Si quieres un entorno inmediatamente lleno de herramientas científicas, Anaconda Distribution resulta cómoda.

Si ya sabes lo que necesitas y prefieres construir progresivamente tu entorno, Miniconda es mucho más ligera.

Se podría resumir así:

Anaconda Distribution: cocina completamente equipada.

Miniconda: habitación vacía con agua y electricidad ya instaladas.

Ambas utilizan conda.

La diferencia depende principalmente de lo que ya está instalado antes incluso de empezar.

¿Y Miniforge?

Miniforge resulta especialmente interesante cuando se busca:

conda;

un instalador mínimo;

conda-forge como fuente predeterminada;

y evitar que el acceso a los repositorios Anaconda forme parte de la ecuación comercial.

Está mantenido por la comunidad conda-forge y no es proporcionado por Anaconda.

Para un desarrollador experimentado que quiere principalmente la mecánica conda sin la distribución Anaconda, es una alternativa extremadamente creíble.

Su paradoja: simplificar instalando mucho

Anaconda facilita el comienzo aportando una enorme cantidad de cosas.

Precisamente eso puede hacerla pesada.

Un entorno mínimo construido con uv o Miniconda puede contener únicamente:

Python;

el gestor;

las cinco bibliotecas necesarias.

Anaconda Distribution llega con un conjunto mucho más amplio.

Para aprender y explorar científicamente, resulta cómodo.

Para un pequeño servicio web de 30 MB cuyas únicas dependencias son FastAPI y HTTPX, bastante menos.

La elección adecuada depende, por tanto, de la densidad real del proyecto.

Anaconda brilla especialmente cuando el problema deja de ser solamente Python y pasa a ser todo lo que debe convivir alrededor de Python.

¿Y en producción?

Anaconda puede formar parte de workflows profesionales serios.

Pero instalar la Distribution completa en cada servidor no es necesariamente el modelo ideal.

Según el contexto, puede ser preferible utilizar:

entornos conda más específicos;

Miniconda;

Miniforge;

contenedores;

repositories privados;

soluciones Anaconda Business;

u otras cadenas de packaging.

La Distribution es excelente como workstation científica.

No debe confundirse con una arquitectura universal de despliegue.

¿Para quién?

Anaconda sigue siendo especialmente pertinente para:

principiantes en data science;

estudiantes e investigadores;

científicos;

analistas de datos;

equipos de machine learning;

usuarios con numerosas dependencias nativas;

personas que prefieren una GUI para gestionar entornos y packages.

Para un desarrollador Python generalista que ya domina sus dependencias, un entorno más mínimo puede resultar más agradable.

Y para alguien que solamente quiere conda:

probablemente no sea necesario instalar toda Anaconda Distribution.

Puntos de atención

Gratuito ya no significa «gratuito para absolutamente todo el mundo»

Es el punto que hay que comprender antes de descargar.

Las condiciones actuales de Anaconda permiten, entre otros casos, el uso gratuito de la plataforma para:

particulares dentro de un uso personal y no comercial;

determinadas instituciones académicas elegibles;

determinadas organizaciones de investigación o sin ánimo de lucro elegibles;

organizaciones comerciales con un máximo de 200 empleados o contratistas, teniendo en cuenta las entidades afiliadas según las condiciones de Anaconda.

Por encima de ese umbral, una organización comercial debe suscribirse a una oferta Business cuando no se aplique ninguna excepción.

Por tanto, ya no basta con decir:

«Anaconda es gratuito».

Una formulación más correcta sería:

Anaconda tiene usos gratuitos y usos comerciales sujetos a licencia.

Los precios abarcan ahora una plataforma más amplia

La oferta actual ya no se limita al instalador desktop.

Los planes mostrados incluyen:

Free: 0 $

Starter: 15 $ por usuario y mes

Business: 50 $ por usuario y mes, con compra directa hasta 15 plazas y contacto comercial para más.

Según el plan, aparecen más almacenamiento cloud, colaboración, notebooks, seguridad, gobernanza, repositories privados, SSO y funciones destinadas a empresas.

Por tanto, hay que distinguir:

el software local;

el acceso a los repositorios;

y los servicios de plataforma.

Meter todo eso en una misma caja llamada «Anaconda» resulta cómodo comercialmente.

Algo menos cuando se intenta comprender exactamente qué se está pagando.

Conda es open source; Anaconda Distribution y sus servicios no deben confundirse con él

conda es open source.

Muchos packages distribuidos por Anaconda también son open source.

Jupyter es open source.

Python es open source.

Una gran parte de lo que contiene el entorno Anaconda posee por tanto su propio código fuente y su propia licencia libre.

Pero eso no significa que Anaconda Distribution, sus repositories y la plataforma Anaconda en su conjunto sean simplemente un producto open source sin condiciones comerciales.

Los Terms of Service de Anaconda se aplican al uso de sus Offerings y repositorios.

Por eso esta ficha clasifica la Distribution como proprietary, dejando claro al mismo tiempo que reúne una enorme cantidad de componentes open source.

Esta diferencia importa.

Miniconda no elimina automáticamente las reglas de los repositories Anaconda

Miniconda es un instalador mínimo.

Su instalación en sí misma no exige una licencia comercial simplemente porque una organización supere las 200 personas.

Pero está configurado por defecto para acceder a los repositories Anaconda.

Y el acceso a esos repositorios puede activar las condiciones comerciales.

Desde julio de 2025, las versiones recientes de Miniconda solicitan además explícitamente la aceptación de los Terms of Service al acceder a los repositorios afectados.

Instalar Miniconda y utilizar defaults no significa, por tanto, haber evitado automáticamente la cuestión de la licencia.

Conda-forge se encuentra en una situación diferente

Anaconda especifica que las obligaciones de pago de sus Terms of Service no se aplican a los packages comunitarios de conda-forge alojados en anaconda.org.

Anaconda aloja esos contenidos, pero no construye por sí misma los packages conda-forge.

Es una de las razones por las que Miniforge + conda-forge constituye una opción especialmente interesante en determinadas organizaciones.

La misma herramienta de gestión de entornos.

Una cadena de distribución diferente.

Una vez más:

conda y Anaconda no son sinónimos.

La Distribution es pesada

Los requisitos oficiales anuncian al menos 5 GB de espacio en disco para descargar e instalar Anaconda Distribution.

Y esto es solo el comienzo.

Cada nuevo entorno conda puede añadir:

una versión de Python;

bibliotecas nativas;

packages científicos;

cachés de instalación.

Varios entornos de machine learning pueden consumir rápidamente decenas de gigabytes.

No es necesariamente un problema en una workstation moderna.

Pero para un pequeño proyecto Python existen soluciones infinitamente más ligeras.

No conviertas base en un trastero

Anaconda tiene un entorno base.

Es tentador instalar progresivamente en él:

Jupyter.

PyTorch.

TensorFlow.

Una biblioteca encontrada el martes.

Un package experimental el viernes.

Después una dependencia antigua necesaria para un proyecto de 2021.

Seis meses más tarde, base se convierte en un museo interactivo de conflictos de versiones.

La propia Anaconda recomienda crear entornos separados para los proyectos.

Probablemente sea el mejor consejo práctico de toda esta ficha.

Mantén base relativamente limpio. Crea un entorno para cada proyecto importante.

Mezclar pip y conda exige saber qué se está haciendo

Es posible utilizar pip dentro de un entorno conda.

A veces incluso es necesario cuando un package no existe en los channels conda elegidos.

Pero ambos gestores no siguen exactamente los mismos metadatos ni el mismo modelo de resolución.

Instalar con conda.

Modificar con pip.

Volver a instalar con conda.

Volver a pip.

Puede acabar produciendo un entorno cuya historia completa no pertenece realmente a ninguno de los dos gestores.

En la práctica, suele ser mejor:

instalar todo lo posible con conda;

después utilizar pip para lo que siga siendo necesario;

y evitar luego idas y vueltas arbitrarias.

Los channels no son intercambiables sin consecuencias

defaults.

conda-forge.

Channels privados.

Repositories internos.

Un entorno puede utilizar varias fuentes.

Pero los packages pueden haberse construido con toolchains, dependencias o convenciones diferentes.

Mezclar channels sin comprender su prioridad puede provocar incompatibilidades difíciles de diagnosticar.

Para muchos proyectos, utilizar una estrategia coherente — por ejemplo conda-forge con prioridad estricta — resulta más predecible que coleccionar channels como extensiones del navegador.

macOS Intel es ahora un caso aparte

Anaconda Distribution 2025.06 fue anunciada como la última versión de la Distribution compatible con Mac Intel mediante osx-64.

Las versiones recientes se orientan por tanto a Apple Silicon en macOS.

Un Mac Intel antiguo puede seguir utilizando versiones históricas de la Distribution y determinados packages existentes.

Pero ya no debe esperarse el mismo nivel de soporte para nuevas releases.

Para un parque de hardware antiguo, este detalle puede resultar decisivo.

Windows 10 también entra en terreno histórico

La documentación de Anaconda indica que el soporte para nuevas releases de packages en Windows 10 terminó el 30 de junio de 2026.

Eso no significa que todas las instalaciones Anaconda existentes en Windows 10 dejen de funcionar de repente al día siguiente.

Pero el ecosistema reciente se está desplazando hacia las versiones de Windows que siguen recibiendo soporte.

A 8 de agosto de 2026, una nueva workstation destinada a un entorno Anaconda moderno tiene por tanto mucho más sentido con Windows 11 que con Windows 10.

Las arquitecturas disponibles no son todas equivalentes

Las versiones actuales se orientan principalmente a:

Windows x86-64;

macOS Apple Silicon ARM64;

Linux x86-64;

Linux ARM64.

En Linux ARM, Anaconda especifica que determinados builds están dirigidos a microarquitecturas de servidor como Neoverse N1/N2.

Por tanto, un Raspberry Pi ARM64 no es automáticamente equivalente a un servidor Graviton simplemente porque ambos indiquen aarch64.

Para pequeñas máquinas ARM, comprobar los builds compatibles sigue siendo indispensable.

Las versiones científicas a veces priorizan la estabilidad frente a la última novedad

Anaconda construye y prueba conjuntos de packages destinados a funcionar juntos.

Esta estrategia puede significar que una biblioteca disponible en el repository Anaconda no sea siempre la versión más reciente publicada en PyPI o conda-forge.

No significa necesariamente que vaya con retraso.

A menudo es el compromiso buscado entre:

novedad;

compatibilidad;

estabilidad;

seguridad;

reproducibilidad.

Para un investigador que quiere absolutamente la feature publicada ayer por la noche, este compromiso puede resultar frustrante.

Para un equipo que quiere recuperar exactamente el mismo entorno mañana por la mañana, puede resultar tranquilizador.

Un entorno no es automáticamente reproducible en todas las plataformas

Un archivo environment.yml ayuda enormemente.

Pero un entorno científico puede depender:

del OS;

de la arquitectura;

de los packages disponibles;

de las bibliotecas nativas;

de la GPU;

de los drivers.

Exportar un entorno macOS y exigir después que reconstruya exactamente la misma pila en Linux no siempre es realista.

Para una reproducibilidad fuerte, hay que pensar más allá de una simple lista de packages:

versiones;

channels;

plataforma;

arquitectura;

y, en algunos casos, contenedores.

Anaconda simplifica la entrada, no todas las etapas posteriores

Probablemente sea la limitación más importante.

Anaconda puede hacer muy sencillo:

instalar Python;

crear un entorno;

instalar packages;

abrir Jupyter.

Pero no elimina:

incompatibilidades;

dependencias difíciles;

problemas de GPU;

diferencias de arquitectura;

actualizaciones que rompen cosas;

packaging de una aplicación;

despliegue;

seguridad de la supply chain.

Elimina mucha fricción.

No convierte el ecosistema científico en un universo sin fricción.

Y quizá sea mejor así.

De lo contrario, los desarrolladores empezarían a preguntarse qué hacer con sus mañanas.

Anaconda no es la manera obligatoria de utilizar Python. Es una manera de hacer que los entornos científicos complejos sean lo bastante normales como para poder, por fin, trabajar con ellos.