Cómo instalar scikit-learn (todos los métodos)

Nuestro interés en este asunto es prácticamente nulo: somos Geonode y vendemos proxies, lo cual no tiene nada que ver con la instalación de una biblioteca de Python. El único punto en el que se cruzan merece una mención: si pip install se cuelga en un entorno corporativo, suele tratarse de un proxy que requiere tu red y del que pip no tiene constancia, y la solución es pip install --proxy o las variables de entorno estándar. Ese caso se trata al final. Todo lo demás aquí no requiere infraestructura ni compra alguna.

La respuesta breve

python -m venv sklearn-env
source sklearn-env/bin/activate          # Windows: sklearn-env\Scripts\activate
pip install -U scikit-learn

O con conda:

conda create -n sklearn-env -c conda-forge scikit-learn
conda activate sklearn-env

La documentación oficial presenta ambas opciones y hace hincapié en el entorno: «el entorno virtual es opcional, pero muy recomendable, para evitar posibles conflictos con otros paquetes».

Añade un recordatorio que suele pasar desapercibido: «Debes recordar siempre activar el entorno que elijas antes de ejecutar cualquier comando de Python cada vez que inicies una nueva sesión de terminal». Gran parte de los casos en los que se dice «ayer funcionaba» se deben a que se trata de una nueva terminal sin el entorno activado.

Por qué falla «pip install sklearn»

La pregunta más habitual en este ámbito, y la respuesta es que se trata de un diseño deliberado.

«sklearn» es el nombre de la importación. «scikit-learn» es el nombre del paquete. Al escribir el primero en pip, se instala un marcador de posición cuyo único propósito es impedir que continúes.

La propia descripción de ese marcador de posición en PyPI no deja lugar a dudas: «paquete sklearn obsoleto, utiliza scikit-learn en su lugar», con la recomendación de «utilizar pip install scikit-learn en lugar de pip install sklearn» y de «sustituir sklearn por scikit-learn en tus archivos de requisitos de pip».

La razón de su existencia tiene que ver con la cadena de suministro, tal y como se explica claramente en su documentación:

El paquete sklearn en PyPI existe para evitar que personas malintencionadas utilicen el paquete sklearn, ya que sklearn (el nombre de importación) y scikit-learn (el nombre del proyecto) a veces se utilizan indistintamente.

En otras palabras, los responsables del mantenimiento se adjudicaron ese nombre que da lugar a confusión para que nadie más pudiera hacerlo. Teniendo en cuenta la cantidad de gente que lo escribe, fue una medida sensata.

La documentación del paquete describe tres casos extremos que conviene conocer si te encuentras con ellos:

• «pip install sklearn==1.1.3 indicará que la versión 1.1.3 no existe, lo cual resulta confuso»: el marcador de posición solo tiene sus propios números de versión.
• «pip uninstall sklearn, en realidad, no desinstalará scikit-learn; aún así, puedes ejecutar import sklearn después».
• Tener ambos en pip list resulta confuso, aunque es normal si los has instalado por error.

Existe una salida de emergencia —configurar SKLEARN_ALLOW_DEPRECATED_SKLEARN_PACKAGE_INSTALL=True— y se describe como «un último recurso». Si te ves obligado a recurrir a ella, la solución real casi siempre es que alguna de tus dependencias incluya sklearn en sus requisitos. Vale la pena seguir el propio consejo del marcador de posición: «rastrea qué paquete utiliza sklearn en lugar de scikit-learn e informa de ello a su gestor de incidencias».

En tus propios archivos, escribe siempre scikit-learn. En tu código, escribe siempre import sklearn. La asimetría es permanente.

Requisitos

Según los metadatos del paquete de la versión actual, consultados en septiembre de 2026.

scikit-learn 1.9.0 se publicó el 2 de junio de 2026 y requiere Python 3.11 o posterior.

Sus dependencias de ejecución:

Dos notas sobre esa tabla.

narwhals es una incorporación relativamente reciente y no aparecerá en documentación más antigua ni en tutoriales escritos para versiones anteriores. Si estás fijando las dependencias manualmente en lugar de dejar que pip las resuelva, esta es la que más probablemente se te pasará por alto.

El umbral de Python cambia. La tabla de dependencias de la página de instalación refleja la versión que documenta, y los requisitos han aumentado en las últimas versiones. Si utilizas una versión antigua de Python, pip resolverá la instalación con una versión anterior de scikit-learn en lugar de dar un error, lo cual suele estar bien y, en ocasiones, explica por qué falta alguna característica de la que hayas leído.

Se declaran elementos opcionales para pruebas de rendimiento, documentación, ejemplos y pruebas, lo que implica la inclusión de matplotlib, pandas, polars, pyarrow y otros. No necesitas ninguno de ellos para utilizar la biblioteca.

Instalación sin entorno virtual

A veces realmente se desea una instalación en todo el sistema, y hay una advertencia al respecto.

La documentación es muy clara en lo que respecta específicamente a Linux: «En concreto, en Linux no se recomienda instalar paquetes pip junto con los paquetes gestionados por el gestor de paquetes de la distribución (apt, dnf, pacman…).»

El motivo es que tanto pip como el gestor de paquetes de tu distribución consideran que son los propietarios de los archivos del directorio site-packages de Python en el sistema, y cuando no se ponen de acuerdo, el resultado es una instalación de Python que se comporta de forma extraña y difícil de desentrañar. En las distribuciones recientes, pip se negará rotundamente con un error de «entorno gestionado externamente», lo cual es precisamente lo que el ecosistema de paquetes pretende evitar.

Si te encuentras con ese error, las opciones, por orden de preferencia, son: utilizar un entorno virtual, utilizar pipx para las herramientas de línea de comandos, utilizar el propio paquete python3-sklearn de tu distribución si lo tiene, o —sabiendo lo que estás haciendo— anularlo con --break-system-packages, una opción cuyo nombre está pensado para disuadirte.

En macOS y Windows la presión es menor, pero el consejo sigue siendo válido. Crear un entorno virtual por proyecto lleva diez segundos y evita toda una categoría de problemas.

Comprobación de la instalación

La documentación proporciona los comandos, y merece la pena dedicar treinta segundos a ejecutarlos.

python -m pip show scikit-learn    # version and install location
python -m pip freeze              # everything in the environment
python -c "import sklearn; sklearn.show_versions()"

Con conda:

conda list scikit-learn
conda list

sklearn.show_versions()

es el comando que hay que utilizar para informar de un problema. Muestra la versión de scikit-learn, la versión y la compilación de Python, así como las versiones de la pila numérica subyacente, que es precisamente la información que cualquier responsable de mantenimiento te pedirá en primer lugar.

Merece la pena echar un vistazo a la ubicación de instalación en pip show

cuando algo se comporte de forma extraña. Si apunta a un lugar distinto del entorno en el que crees que te encuentras, ahí tienes la respuesta: import sklearn

encontrará la instalación que aparezca primero en la ruta, y puede que no sea la que acabas de instalar.

conda frente a pip

Ambos funcionan. La elección es importante sobre todo si los utilizas de forma combinada, algo que no deberías hacer a la ligera.

Utiliza conda cuando ya tengas un entorno conda, cuando necesites bibliotecas numéricas compiladas específicas o cuando te encuentres en una plataforma en la que, de otro modo, sería necesario compilar desde el código fuente. Da preferencia a conda-forge como canal, tal y como indican las instrucciones oficiales.

Utiliza pip cuando te encuentres en un entorno virtual de Python normal, lo cual cubre la mayoría de los proyectos. Los archivos «wheels» se publican para las plataformas más comunes, por lo que no hay que compilar nada y la instalación tarda unos segundos.

No los mezcles en un mismo entorno sin pensarlo bien. Instalar un paquete con conda y luego actualizar una dependencia con pip da lugar a un entorno en el que los metadatos de conda ya no reflejan la realidad, y los fallos resultantes son difíciles de diagnosticar. Si no tienes más remedio, instala primero todo lo que puedas con conda y solo entonces utiliza pip para lo que conda no tenga.

Hay una forma práctica de saber en qué entorno te encuentras: si which python apunta al interior de un directorio del entorno de conda, utiliza conda para ese entorno.

Errores habituales tras la instalación

ModuleNotFoundError: No module named 'sklearn' tras una instalación correcta. Casi siempre se debe a un entorno incorrecto: un terminal diferente, un intérprete distinto o un kernel de cuaderno que apunta a otra ubicación. Compruébalo con:

import sys; print(sys.executable)

y compáralo con el entorno en el que lo has instalado. En Jupyter, concretamente, el kernel se elige por separado del entorno de la terminal, y la instalación en uno no afecta al otro. %pip install scikit-learn dentro del cuaderno se instala en el entorno del kernel, lo cual es la solución fiable.

ImportError que menciona NumPy o una incompatibilidad binaria. Normalmente se trata de una discrepancia entre versiones compiladas, causada en la mayoría de los casos por actualizar NumPy de forma independiente. Reinstalar ambos a la vez lo resuelve:

pip install --force-reinstall --no-cache-dir numpy scipy scikit-learn

Una compilación que intenta compilar desde el código fuente. Esto significa que ningún archivo «wheel» se ajustaba a tu plataforma y versión de Python; suele ser una versión muy reciente de Python antes de que se publiquen los archivos «wheel», o una arquitectura poco habitual. Es más sencillo esperar unas semanas o utilizar una versión de Python ligeramente anterior que instalar una cadena de herramientas de compilación.

Tanto sklearn como scikit-learn en pip list. En algún momento instalaste el marcador de posición. Eliminarlo es seguro: pip uninstall sklearn. Tal y como indica su documentación, esto «en realidad no desinstalará scikit-learn».

Advertencias sobre subprocesos o threadpoolctl. scikit-learn lo utiliza para gestionar los grupos de subprocesos de las bibliotecas BLAS subyacentes. Establecer OMP_NUM_THREADS de forma explícita resuelve la mayoría de estos problemas, y merece la pena hacerlo de todos modos en contenedores, donde una biblioteca sin restricciones creará sin problemas un subproceso por cada CPU del host, independientemente de tu límite de CPU.

Fijar versiones para garantizar la reproducibilidad

La instalación es algo que se hace una sola vez; mantener la misma instalación el mes que viene es el problema más difícil, y merece la pena prepararlo antes de que lo necesites.

Fíjalo en un archivo de requisitos, no en tu cabeza. Un simple «pip install scikit-learn

» hoy y el mismo comando dentro de seis meses te darán versiones diferentes, y la API de scikit-learn sí cambia entre versiones menores: los estimadores ganan parámetros, los valores por defecto cambian y, en ocasiones, se elimina algo tras un ciclo de obsolescencia:

scikit-learn==1.9.0
numpy==2.3.1
scipy==1.16.0

Fija también la pila numérica, no solo scikit-learn. La mayoría de los fallos de reproducibilidad en este ecosistema se deben a que NumPy o SciPy cambian bajo un scikit-learn fijado, ya que las interfaces compiladas entre ellos son más estrechas de lo que sugieren los especificadores de versión. Fijar la parte superior del árbol y dejar que el resto flote es la configuración con más probabilidades de fallar.

Genera el archivo desde un entorno de trabajo en lugar de escribirlo:

pip freeze > requirements.txt

Así se recoge todo, incluidas las dependencias transitivas, que es lo que se busca para una aplicación. Para una biblioteca que vayas a publicar, especifica rangos y deja que los usuarios lo resuelvan: una biblioteca que fije versiones exactas se vuelve imposible de combinar con cualquier otra cosa.

Registra las versiones junto con tus resultados. Los resultados de los modelos dependen de la versión de la biblioteca, y un modelo guardado no es portable entre versiones arbitrarias: al desempaquetar un estimador guardado por una versión diferente pueden aparecer advertencias, fallar o comportarse de forma diferente sin avisar. Almacenar una salida de «sklearn.show_versions()

» junto a cualquier modelo persistido convierte un futuro misterio en una simple consulta.

Y desconfía de los modelos «pickled» como formato de almacenamiento. Incorporan la estructura de clases de la versión que los creó, por lo que dejan de funcionar tras las actualizaciones, y ejecutan código al cargarse; así pues, un archivo «pickle» procedente de una fuente no fiable supone la ejecución de código arbitrario, en lugar de ser un simple archivo de datos. Para cualquier elemento de larga duración, es preferible utilizar un formato diseñado para el intercambio o, como mínimo, conservar el código de entrenamiento y los datos para que el modelo pueda reconstruirse.

Instalación detrás de un proxy corporativo

Este es el único caso en el que nuestro tema es relevante y el síntoma es característico.

Si pip install

se cuelga y luego se agota el tiempo de espera, en lugar de fallar rápidamente con un error de resolución de nombres, es probable que tu red requiera un proxy que pip no conoce.

pip install --proxy http://user:password@proxy.example.com:9000 scikit-learn

O a través del entorno, lo cual se aplica también a conda y a la mayoría de las demás herramientas:

export https_proxy=http://user:password@proxy.example.com:9000
export http_proxy=http://user:password@proxy.example.com:9000

Hay dos cosas que suelen salir mal en este caso.

Los caracteres especiales de la contraseña deben codificarse con el símbolo de porcentaje. Un @

o un :

en una URL de proxy divide la cadena en el lugar equivocado, lo que provoca un error de autenticación incluso con las credenciales correctas.

La interceptación de TLS impide la verificación del certificado. Los proxies corporativos suelen interrumpir la conexión TLS, y pip rechaza entonces el certificado porque ha sido emitido por la autoridad de tu organización en lugar de por una pública. La solución correcta es indicar a pip el paquete de CA de tu organización:

pip config set global.cert /path/to/corporate-ca.pem

La solución más tentadora es --trusted-host pypi.org

, que desactiva la verificación para ese host. Infórmate bien de lo que esto implica antes de utilizarlo: estás optando por aceptar cualquier certificado que se presente para el servidor del que descargas código ejecutable.

Para conda, la configuración equivalente se encuentra en .condarc

, en proxy_servers

y ssl_verify

.

Preguntas frecuentes

¿Cómo instalo scikit-learn?

pip install -U scikit-learn dentro de un entorno virtual, o conda create -n sklearn-env -c conda-forge scikit-learn con conda. La documentación recomienda encarecidamente utilizar un entorno virtual para evitar conflictos con otros paquetes.

¿Por qué falla la instalación de sklearn con pip?

Porque sklearn es el nombre de importación, no el nombre del paquete. En PyPI existe un paquete ficticio cuyo único propósito es generar un error y redirigirte; sus mantenedores eligieron ese nombre confuso precisamente para evitar que alguien malintencionado publicara bajo ese nombre. Instala scikit-learn en su lugar.

¿Cuál es la diferencia entre sklearn y scikit-learn?

scikit-learn es el nombre del proyecto y del paquete que se utiliza con pip y conda; sklearn es el nombre que se utiliza en las instrucciones «import». Esta asimetría es permanente y es la razón por la que existe el paquete de marcador de posición.

¿Qué versión de Python necesita scikit-learn?

La versión 1.9.0, publicada en junio de 2026, requiere Python 3.11 o posterior. Las versiones anteriores de scikit-learn son compatibles con versiones anteriores de Python, y pip seleccionará una versión compatible en lugar de dar un error —lo cual explica a veces por qué falta alguna característica de la que hayas leído.

¿Por qué me aparece un error «ModuleNotFoundError» tras la instalación?

Casi siempre se debe a un entorno incorrecto. Comprueba import sys; print(sys.executable) y compáralo con el lugar donde lo has instalado. En Jupyter, el entorno del kernel es independiente del de tu terminal: utiliza %pip install scikit-learn dentro del cuaderno para instalarlo en el kernel.

¿Debería usar pip o conda?

Usa pip en un entorno virtual normal, que se adapta a la mayoría de los proyectos e instala «wheels» precompilados en segundos. Usa conda si ya te encuentras en un entorno conda o si necesitas bibliotecas numéricas compiladas específicas. Evita mezclarlos en un mismo entorno, ya que las visiones que tienen de él los dos gestores de paquetes divergirán.

¿Cómo compruebo qué versión de scikit-learn tengo?

python -m pip show scikit-learn para ver la versión y la ubicación de instalación, o python -c "import sklearn; sklearn.show_versions()" para obtener un informe completo que incluye Python y la pila numérica —que es lo que debes incluir al informar de un problema—.

¿Cómo instalo scikit-learn detrás de un proxy?

Utiliza pip install --proxy http://user:pass@host:port scikit-learn, o configura http_proxy y https_proxy en tu entorno para que conda y otras herramientas también los detecten. Codifica los caracteres especiales de la contraseña con el símbolo de porcentaje y configura el certificado de la autoridad de certificación (CA) de tu organización en lugar de desactivar la verificación.

Conclusión

La instalación en sí misma se realiza con un solo comando. Casi toda la dificultad de este tema proviene de dos aspectos que no tienen nada que ver con el código propio de scikit-learn.

El primero es el nombre. «scikit-learn» para instalar, «sklearn» para importar, y un paquete provisional con un nombre que puede dar lugar a confusión para detenerte y explicarte por qué. Ese paquete de relleno es una pequeña medida de buena higiene en la cadena de suministro, y el error que genera está cumpliendo su función.

La segunda son los entornos. Un gran número de fallos —el módulo que desaparece en una nueva terminal, el cuaderno que no encuentra lo que acabas de instalar, el error de importación tras una actualización no relacionada— son un mismo problema de entorno con diferentes manifestaciones. Un entorno virtual por proyecto, activado deliberadamente, evita casi todos ellos, y «print(sys.executable)» diagnostica el resto en una sola línea.

Y si «pip» se cuelga en lugar de dar un error, revisa tu red antes que tu Python. Un proxy obligatorio que pip no reconoce provoca un tiempo de espera agotado en lugar de un error, lo cual es una forma confusa de conocer tu propia infraestructura.