How to Install scikit-learn (All Methods)

Our stake here is essentially nil: we are Geonode and we sell proxies, which have nothing to do with installing a Python library. The one place they intersect is worth a sentence — if pip install hangs in a corporate environment, that is usually a proxy your network requires and pip does not know about, and the fix is pip install --proxy or the standard environment variables. That case is covered at the end. Everything else here needs no infrastructure and no purchase.

The Short Answer

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

Or with conda:

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

The official documentation presents both, and is emphatic about the environment: "the virtual environment is optional but strongly recommended, in order to avoid potential conflicts with other packages".

It adds a reminder that catches people out constantly: "You should always remember to activate the environment of your choice prior to running any Python command whenever you start a new terminal session." A great many "it was working yesterday" reports are a new terminal with no activated environment.

Why pip install sklearn Fails

The single most common question in this area, and the answer is deliberate design.

sklearn is the import name. scikit-learn is the package name. Typing the first into pip installs a placeholder whose entire purpose is to stop you.

That placeholder's own description on PyPI is unambiguous: "deprecated sklearn package, use scikit-learn instead", with the guidance to "use pip install scikit-learn rather than pip install sklearn" and to "replace sklearn by scikit-learn in your pip requirements files".

The reason it exists is a supply-chain one, stated plainly in its documentation:

sklearn package on PyPI exists to prevent malicious actors from using the sklearn package, since sklearn (the import name) and scikit-learn (the project name) are sometimes used interchangeably.

In other words, the maintainers claimed the confusable name so that nobody else could. Given how many people type it, that was a sensible thing to do.

The package documents three edge cases worth knowing if you meet them:

• "pip install sklearn==1.1.3 will say that the 1.1.3 version does not exist, which is confusing" — the placeholder has only its own version numbers.
• "pip uninstall sklearn will actually not uninstall scikit-learn, you can still do import sklearn afterwards".
• Having both in pip list is confusing and normal if you installed both by accident.

There is an escape hatch — setting SKLEARN_ALLOW_DEPRECATED_SKLEARN_PACKAGE_INSTALL=True — and it is described as "a last resort". If you find yourself reaching for it, the real fix is almost always a dependency of yours listing sklearn in its requirements. The placeholder's own advice is worth following: "track which package uses sklearn instead of scikit-learn and report it to their issue tracker".

In your own files, always write scikit-learn. In your code, always write import sklearn. The asymmetry is permanent.

Requirements

From the package metadata for the current release, checked in September 2026.

scikit-learn 1.9.0 was published on 2 June 2026 and requires Python 3.11 or later.

Its runtime dependencies:

Two notes on that table.

narwhals is a relatively recent addition and will not appear in older documentation or in tutorials written against earlier releases. If you are pinning dependencies by hand rather than letting pip resolve them, this is the one you are most likely to miss.

The Python floor moves. The installation page's dependency table reflects whichever release it documents, and the requirement has risen over recent versions. If you are on an older Python, pip will resolve to an older scikit-learn rather than failing — which is usually fine and occasionally the explanation for a missing feature you read about.

Optional extras are declared for benchmarking, documentation, examples and tests, pulling in matplotlib, pandas, polars, pyarrow and others. You do not need any of them to use the library.

Installing Without a Virtual Environment

Sometimes you genuinely want a system-wide install, and there is a warning attached.

The documentation is direct about Linux specifically: "In particular under Linux it is discouraged to install pip packages alongside the packages managed by the package manager of the distribution (apt, dnf, pacman…)."

The reason is that both pip and your distribution's package manager believe they own the files in the system Python's site-packages, and when they disagree the result is a Python installation that behaves oddly in ways that are difficult to unpick. On recent distributions pip will refuse outright with an "externally managed environment" error, which is the packaging ecosystem preventing exactly this.

If you meet that error, the options in order of preference are: use a virtual environment, use pipx for command-line tools, use your distribution's own python3-sklearn package if it has one, or — knowing what you are doing — override with --break-system-packages, a flag named to discourage you.

On macOS and Windows the pressure is lower but the advice stands. A virtual environment per project takes ten seconds and prevents an entire category of problem.

Verifying the Install

The documentation gives the commands, and running them is worth the thirty seconds.

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()"

With conda:

conda list scikit-learn
conda list

sklearn.show_versions() is the one to use when reporting a problem. It prints the scikit-learn version, the Python version and build, and the versions of the numerical stack underneath — which is precisely the information any maintainer will ask for first.

The install location in pip show deserves a look when something is behaving strangely. If it points somewhere other than the environment you think you are in, you have your answer: import sklearn will find whichever installation comes first on the path, and that may not be the one you just installed.

conda Versus pip

Both work. The choice matters mainly if you are mixing them, which you should not do casually.

Use conda when you already have a conda environment, when you need specific compiled numerical libraries, or when you are on a platform where building from source would otherwise be required. Prefer conda-forge as the channel, as the official instructions do.

Use pip when you are in an ordinary Python virtual environment, which covers most projects. Wheels are published for the common platforms, so nothing compiles and the install takes seconds.

Do not mix them in one environment without thinking. Installing a package with conda and then upgrading a dependency with pip produces an environment where conda's metadata no longer describes reality, and the resulting breakage is unpleasant to diagnose. If you must, install everything you can with conda first and only then use pip for what conda does not have.

There is a practical tell for which you are in: if which python points inside a conda environment directory, use conda for that environment.

Common Errors After Installing

ModuleNotFoundError: No module named 'sklearn' after a successful install. Almost always the wrong environment — a different terminal, a different interpreter, or a notebook kernel pointing elsewhere. Check with:

import sys; print(sys.executable)

and compare against the environment you installed into. In Jupyter specifically, the kernel is a separate choice from the terminal environment, and installing in one does nothing for the other. %pip install scikit-learn inside the notebook installs into the kernel's environment, which is the reliable fix.

ImportError mentioning NumPy or a binary incompatibility. Usually a mismatch between compiled versions, most often caused by upgrading NumPy independently. Reinstalling both together resolves it:

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

A build attempting to compile from source. This means no wheel matched your platform and Python version — commonly a very new Python release before wheels are published, or an unusual architecture. Waiting a few weeks or using a slightly older Python is easier than installing a build toolchain.

Both sklearn and scikit-learn in pip list. You installed the placeholder at some point. Removing it is safe: pip uninstall sklearn. As its documentation notes, this "will actually not uninstall scikit-learn".

Warnings about threads or threadpoolctl. scikit-learn uses it to manage the thread pools of the underlying BLAS libraries. Setting OMP_NUM_THREADS explicitly resolves most of these, and is worth doing anyway in containers, where an unconstrained library will happily create one thread per host CPU regardless of your CPU limit.

Pinning Versions for Reproducibility

Installing is a one-off; keeping the same install next month is the harder problem, and it is worth setting up before you need it.

Pin in a requirements file, not in your head. A bare pip install scikit-learn today and the same command in six months give you different versions, and scikit-learn's API does change between minor releases — estimators gain parameters, defaults shift, and occasionally something is removed after a deprecation cycle:

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

Pin the numerical stack too, not just scikit-learn. Most reproducibility failures in this ecosystem come from NumPy or SciPy moving underneath a pinned scikit-learn, because the compiled interfaces between them are tighter than the version specifiers suggest. Pinning the top of the tree and letting the rest float is the arrangement most likely to break.

Generate the file from a working environment rather than writing it:

pip freeze > requirements.txt

That captures everything including transitive dependencies, which is what you want for an application. For a library you are publishing, specify ranges instead and let consumers resolve — a library that pins exact versions makes itself impossible to combine with anything.

Record the versions alongside your results. Model outputs depend on the library version, and a saved model is not portable across arbitrary versions — unpickling an estimator saved by a different release may warn, fail, or silently behave differently. Storing sklearn.show_versions() output next to any persisted model turns a future mystery into a lookup.

And be sceptical of pickled models as a storage format. They embed the class structure of the version that created them, which is why they break across upgrades, and they execute code on load — so a pickle from an untrusted source is arbitrary code execution rather than a data file. For anything long-lived, prefer a format designed for interchange, or at minimum keep the training code and data so the model can be rebuilt.

Installing Behind a Corporate Proxy

The one place our own subject matter is relevant, and the symptom is distinctive.

If pip install hangs and then times out, rather than failing quickly with a name-resolution error, your network probably requires a proxy that pip does not know about.

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

Or through the environment, which applies to conda and most other tools as well:

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

Two things that commonly go wrong here.

Special characters in the password need percent-encoding. An @ or a : in a proxy URL splits the string in the wrong place, producing an authentication failure with correct credentials.

TLS interception breaks certificate verification. Corporate proxies frequently terminate TLS, and pip then rejects the certificate because it was issued by your organisation's authority rather than a public one. The correct fix is to point pip at your organisation's CA bundle:

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

The tempting fix is --trusted-host pypi.org, which disables verification for that host. Understand what that costs before using it: you are choosing to accept whatever certificate is presented for the server you download executable code from.

For conda, the equivalent configuration lives in .condarc under proxy_servers and ssl_verify.

People Also Ask

How do I install scikit-learn?

pip install -U scikit-learn inside a virtual environment, or conda create -n sklearn-env -c conda-forge scikit-learn with conda. The documentation strongly recommends a virtual environment to avoid conflicts with other packages.

Why does pip install sklearn fail?

Because sklearn is the import name, not the package name. A placeholder package exists on PyPI whose only purpose is to error and redirect you — its maintainers claimed the confusable name specifically to prevent someone malicious from publishing under it. Install scikit-learn instead.

What is the difference between sklearn and scikit-learn?

scikit-learn is the project and package name used with pip and conda; sklearn is the name you use in import statements. This asymmetry is permanent, and it is the reason the placeholder package exists.

What Python version does scikit-learn need?

Version 1.9.0, published in June 2026, requires Python 3.11 or later. Older scikit-learn releases support older Pythons, and pip will resolve to a compatible version rather than failing — which is sometimes why a feature you read about is missing.

Why do I get ModuleNotFoundError after installing?

Nearly always the wrong environment. Check import sys; print(sys.executable) and compare against where you installed. In Jupyter, the kernel's environment is separate from your terminal's — use %pip install scikit-learn inside the notebook to install into the kernel.

Should I use pip or conda?

pip in an ordinary virtual environment, which suits most projects and installs prebuilt wheels in seconds. conda if you are already in a conda environment or need specific compiled numerical libraries. Avoid mixing them in one environment, since the two package managers' views of it will diverge.

How do I check which version of scikit-learn I have?

python -m pip show scikit-learn for the version and install location, or python -c "import sklearn; sklearn.show_versions()" for a full report including Python and the numerical stack — which is what to include when reporting a problem.

How do I install scikit-learn behind a proxy?

Use pip install --proxy http://user:pass@host:port scikit-learn, or set http_proxy and https_proxy in your environment so conda and other tools pick them up too. Percent-encode special characters in the password, and configure your organisation's CA certificate rather than disabling verification.

Wrapping Up

The install itself is one command. Nearly all the difficulty in this topic comes from two things that have nothing to do with scikit-learn's own code.

The first is the name. scikit-learn to install, sklearn to import, and a placeholder package sitting on the confusable name to stop you and explain why. That placeholder is a small piece of good supply-chain hygiene, and the error it produces is doing its job.

The second is environments. A great many failures — the module that vanishes in a new terminal, the notebook that cannot find what you just installed, the import error after an unrelated upgrade — are one environment problem wearing different clothes. A virtual environment per project, activated deliberately, prevents nearly all of them, and print(sys.executable) diagnoses the rest in one line.

And if pip hangs rather than failing, look at your network before your Python. A required proxy that pip does not know about produces a timeout rather than an error, which is a confusing way to learn about your own infrastructure.