4ml
☰ Menu

Since December 2018 · Updated June 2026

A Practical Python Environment for Artificial Intelligence

A practical installation and tooling guide for AI, ML, CV and NLP in Python written for AI scientists, students and lab teams.

By Warith Harchaoui, Mohamed Chelali, Matias Tassano, Pierre-Louis Antonsanti, Bachir Zerroug and Edmond Jacoupeau.

Battle-tested at the MAP5 applied-mathematics lab. Suggestions and corrections welcome — please contact Warith Harchaoui.

Introduction

This page answers a single, recurring question: what should I actually install today to do ML / CV / NLP work in Python?

It is opinionated on purpose. The default in section 1 is the one we install on every fresh laptop in the lab; the decision table in section 2 covers the situations where the default needs to bend. Sections 3–6 cover the libraries, the GPU question, the notebook / editor / agent layer and the path from notebook to deployable demo. Section 7 is the long, copy-pasteable per-OS recipe. Section 8 is the philosophy — when and why we keep an Open Source counterpart next to every commercial API.

The page is updated as the field moves; the install commands here are what we would run today, not what we would have run two years ago.

Contents

  1. What should I install today?
  2. Which setup matches my situation?
  3. Core Python and ML stack
  4. GPU choices: CUDA vs Apple Silicon
  5. Notebooks, IDEs and AI coding agents
  6. From notebooks to small applications
  7. Full installation recipes
  8. Historical and philosophical notes

1. What should I install today?

If you only read one section of this page, read this one.

You need Miniconda first. The commands below use conda, which comes with Miniconda (a small Anaconda). The install line is OS-specific, so grab the one-liner for your machine from section 7Ubuntu, macOS (Apple Silicon) or Windows 11 — then come back. If conda --version already works in your terminal, skip ahead.

Once conda is on your PATH, open a fresh terminal and run:

conda create -n env4ml python=3.12
conda activate env4ml
pip install scikit-learn pandas matplotlib seaborn jupyterlab
pip install torch torchvision torchaudio

That gives you classical ML (scikit-learn), data tooling (pandas, matplotlib, seaborn), interactive notebooks (JupyterLab) and deep learning (PyTorch). PyTorch ships its mps (Apple Silicon) and CUDA back-ends in the same wheel — the default install picks the right one for your machine.

Need an NVIDIA-CUDA-specific wheel, a Windows native path, or the classroom variant without PyTorch? Each one is a small tweak; the per-OS recipes are in section 7. Does your situation not match this default at all? Check the decision table in section 2. No local install? Google Colab hands you a remote GPU notebook with NumPy / pandas / scikit-learn / PyTorch pre-installed.

Before you install — a few practical warnings

2. Which setup matches my situation?

The default install in section 1 covers most readers. If your situation is more specific — a particular GPU, a teaching constraint, a cloud-only workflow — pick the row that matches and follow that path.

Your situation Recommended setup Why
Laptop, CPU only, just getting started. Python + venv / uv + JupyterLab + scikit-learn (+ PyTorch CPU when needed). Smallest install, fewest moving parts, runs everywhere.
Apple Silicon Mac (M-series). PyTorch with mps for most workflows; MLX for Apple-native experimentation. Strong local performance and unified memory; limited for very large training jobs.
You have an NVIDIA GPU. PyTorch with CUDA — install via the official selector, or conda-forge when binary deps fight you. The most mature GPU path for deep learning at any scale.
No GPU and need one for a few hours. Google Colab. Free or paid GPU/TPU runtimes, zero local setup.
Cloud or self-managed server (Linux + NVIDIA). Ubuntu LTS + Miniconda + PyTorch CUDA, driven via SSH or remote VS Code / Cursor. Same stack as your laptop, real GPU horsepower, reproducible images.
Teaching a class or running a workshop. CPU-only conda + pip env, pinned requirements.txt, Colab as the fallback. Reproducibility beats performance. Every student should be able to follow along.
Heavy scientific Python (compiled deps, geo, bioinformatics). conda-forge throughout, or a carefully pinned uv / pip environment. Avoids most binary-dependency pain.
You want to turn an experiment into a small web app. Streamlit, Gradio or Taipy — or Front if you want the result to look like your project, not the toolkit. Section 6 walks through the notebook → demo pipeline.

3. Core Python and ML stack

Across the decades, the ML community has shifted from Java to MATLAB to Python. The trillion-dollar companies have settled on Python, and the research community has followed with funding and tooling. We recommend Python for your ML projects to align with that scientific and industrial consensus — not as personal taste but as a pragmatic default. Teams on R or Java can still ship through ONNX-R and DL4J; Rust is steadily gaining ground — see "Are we learning yet?".

Ordered chronologically by the first release of the lead tool, so the list doubles as a short history of the field. Notebooks, IDEs and AI coding agents have their own section (section 5) so this list stays focused on libraries and frameworks.

AI helpers

A set of Python utility libraries Warith maintains on GitHub — the full index lives at harchaoui.org/warith/ai-helpers. Each one wraps a specific corner of the AI / media stack so you do not have to re-implement the same plumbing in every project.

4. GPU choices: NVIDIA CUDA vs Apple Silicon

Two hardware paths dominate practical ML in 2026, and they cover different jobs. The choice is a practical one, not an ideological one — pick the one that matches the workload in front of you.

NVIDIA CUDA

The reference setup for serious GPU training. Mature ecosystem, the broadest model zoo, the most third-party tooling, and the only realistic path for large-scale training and high-throughput inference.

Apple Silicon (M-series)

Now genuinely useful for local ML work. Unified memory and quiet hardware make it excellent for experimentation, prototyping, teaching and many small-to-medium workflows. It is not a drop-in replacement for CUDA at the high end.

Practical rule

Develop and prototype on whatever machine sits in front of you — Apple Silicon makes this comfortable. When the experiment outgrows the laptop, move to a CUDA box, a cloud GPU or a cluster. GPU setup is where most of the installation pain lives, so do the move when it has actually paid for itself, not before.

5. Notebooks, IDEs and AI coding agents

The environment in which you actually write the code matters almost as much as the libraries underneath it. This section covers the three layers most ML practitioners touch every day: notebooks for exploration, editors for serious work, and the new generation of AI coding agents sitting on top of both.

Notebooks

Editors

VS Code is still the safe default for everyday ML development. Two AI-first forks have changed the landscape since 2023:

AI coding agents — a new abstraction level

Programming has always advanced one abstraction layer at a time. Machine code gave way to assembly. Assembly gave way to C. C gave way to Python, JavaScript, Rust. Each new layer let programmers express more intent and offload more mechanism onto a tool: the compiler. Large language models add the next layer — natural language as the source artefact, with code as the compiled output.

“The hottest new programming language is English.”

Andrej Karpathy, tweet, January 24, 2023.

That is the optimist's framing. The same observation, viewed from the other end of the abstraction stack, comes from the creator of Linux:

“AI is a great new tool, but it's a tool, and when I see people saying, ‘Hey, 99% of our code is written by AI,’ I literally get angry, because those same people — I can pretty much guarantee — that 100% of their code is written by compilers.”

— Linus Torvalds, keynote at the Open Source Summit North America, Minneapolis, May 2026. Video clip.

Both statements are correct, at the same time. Karpathy is marking the new floor — most people will reach a useful program by writing English rather than Python. Torvalds is marking the ceiling — the engineer who understands what the compiler (or the model) actually produced is still the one who can debug it, optimise it and ship it. Engineering judgment, debugging, testing, architecture and taste have not gone anywhere. AI coding agents help most when the human already knows what they are trying to build — they amplify intent, they do not supply it.

For an ML student today, the practical synthesis is straightforward: treat AI coding agents as the next compiler — write your intent clearly, and read the output critically. The two we use most:

Two coding agents we recommend

Claude Code

Anthropic's official CLI agent. Reads your repo, runs commands, edits files and follows project-specific skills declared under ~/.claude/skills/. Particularly strong at code review, refactors, end-to-end debugging and multi-file edits.

OpenCode

Open-source terminal coding agent that drives Claude, GPT or local models behind the same UX. Reads the same skill format from ~/.opencode/skills/. Pick it when you want to avoid vendor lock-in or run a local model for sensitive code.

6. From notebooks to small applications

Every ML project tends to follow the same trajectory:

Notebook → script → CLI → small web UI → deployable demo

You start in a notebook to find the model that works. You promote the useful cells to a script so the experiment is reproducible. You wrap the script in a CLI so a colleague can run it without reading your code. You wrap the CLI in a small web UI so a stakeholder can try it without a terminal. And, if it survives that, you deploy it.

Different tools fit different rungs of this ladder. Here is how I pick.

Python-first auto-form generators

For the fastest path from notebook to interactive app, the Python-first options are Streamlit, Gradio and Taipy. Each generates a usable web form from Python code in minutes and covers the 80% case very well. The price you pay is that the result looks like a Streamlit, Gradio or Taipy app — their CSS is hard to override cleanly, so apps from any of them tend to look alike.

When you already have a CLI: Front

Many ML projects end up with a working Python CLI before anything else (argparse, click, typer). At that point, the question becomes "how do I put a usable interface on top of this CLI without rewriting it as a Streamlit app?". Front is one answer: an open-source skill for Claude Code and OpenCode that pins the agent to a single frontend stack — vanilla JavaScript, Tailwind CSS, Montserrat (or Inter) — and hands it a curated design system.

Asking the agent to "wrap this CLI in a GUI" produces a single-page index.html + app.js + Tailwind config that maps every argparse / click flag onto the right form control and streams the CLI's output to a log panel. No framework lock-in, no Python runtime, no "Gradio look" — just plain HTML you can edit.

Install with Claude Code

git clone https://github.com/warith-harchaoui/front.git
mkdir -p ~/.claude/skills
cp -r front/front-ui      ~/.claude/skills/front-ui
cp -r front/front-cli-gui ~/.claude/skills/front-cli-gui
cp -r front/front-publish ~/.claude/skills/front-publish
cp -r front/front-a11y    ~/.claude/skills/front-a11y

Or OpenCode

mkdir -p ~/.opencode/skills
cp -r front/front-* ~/.opencode/skills/

Repo: github.com/warith-harchaoui/front — public domain (Unlicense).

Why this matters for ML practitioners

When the demo needs to ship

Once you have an HTML page driving a CLI, packaging is straightforward: Tauri for a desktop app, FastAPI for a hosted demo with a clean HTTP boundary, an ONNX export when you need the model to leave Python entirely. Each of these is a small additional step — not a full rewrite — because the CLI, the model and the UI stay loosely coupled.

Serving the model in production

Model serving hosts the trained model (in the cloud or on-premises) and exposes it through an API so applications can plug AI into their workflow. For cross-language portability, ONNX is both a model file format and a deployment runtime, backed by an open-source community together with Microsoft and the Linux Foundation AI. Prototype in Python, then deploy the ONNX file through ONNX Runtime in C / C++, C#, Java, JavaScript or Objective-C.

For performance-critical paths, the well-trodden route is still C / C++ called from a higher-level language. On the Python side, the best experience comes from pybind11 (Meta used it for fastText); Cython remains a solid option — scikit-learn is its most visible showcase; Numba is a pleasant just-in-time alternative for hot loops. Apple's coremltools lets you tap the Neural Engine from Python at inference time.

7. Full installation recipes

These recipes are the long form of section 1. Use them when you are setting up a fresh machine, when you need NVIDIA / CUDA drivers, or when you want a Linux-like environment on Windows. Throughout, the environment is named env4ml and the Python version is 3.12 — PyTorch and most maintained packages support 3.12 by default.

Ubuntu (22.04 LTS or higher)

  1. Install Miniconda:

    mkdir -p ~/miniconda3
    wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh
    bash ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3
    rm -rf ~/miniconda3/miniconda.sh
    ~/miniconda3/bin/conda init bash
    

    Close and reopen the terminal, then create the environment:

    ENV=env4ml
    conda update -y -n base -c defaults conda
    conda create -y -n $ENV python=3.12
    conda activate $ENV
    conda install -y pip
    pip install scikit-learn pandas matplotlib seaborn jupyterlab
    
  2. NVIDIA driver and CUDA — follow the Google Cloud instructions on your local machine. Mandatory for NVIDIA acceleration.

    Then install PyTorch with the matching CUDA wheel via the official selector — for example:

    pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

  3. Activate the environment for each session:

    ENV=env4ml
    conda activate $ENV
    

macOS (Sonoma 14 or higher, Apple Silicon)

On Apple Silicon Macs, the situation has improved dramatically. PyTorch can target Apple's Metal Performance Shaders backend through the mps device, which makes local experimentation and prototyping comfortable. Apple also develops MLX, a NumPy-like array framework with autodiff designed for ML research on Apple Silicon. Both are excellent for local work; for heavy training, CUDA on NVIDIA GPUs remains the reference (see section 4).

  1. Command-line tools and Homebrew:

    xcode-select --install
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    brew install wget
    
  2. Install Miniconda (Apple Silicon, arm64):

    mkdir -p ~/miniconda3
    curl https://repo.anaconda.com/miniconda/Miniconda3-latest-MacOSX-arm64.sh -o ~/miniconda3/miniconda.sh
    bash ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3
    rm -rf ~/miniconda3/miniconda.sh
    ~/miniconda3/bin/conda init zsh
    

    Close and reopen the terminal, then create the environment:

    ENV=env4ml
    conda update -y -n base -c defaults conda
    conda create -y -n $ENV python=3.12
    conda activate $ENV
    conda install -y pip
    pip install scikit-learn pandas matplotlib seaborn jupyterlab
    pip install torch torchvision torchaudio
    

Windows 11

For 2026 we recommend Windows 11 for native Windows users. For any serious ML work on Windows, we strongly recommend WSL2 (Windows Subsystem for Linux 2). WSL2 gives you a real Linux kernel and a Linux-like development environment that mirrors most cloud and server workflows — meaning the same installation commands work on your laptop, on a CI runner and on a remote GPU box.

From an elevated PowerShell:

wsl --install -d Ubuntu

Then open the Ubuntu shell and follow the Ubuntu recipe above. NVIDIA CUDA in WSL2 is supported through the official NVIDIA CUDA on WSL guide.

Native Windows path

If you really need a native Windows environment (for example because a vendor SDK is Windows-only):

  1. Install Miniconda:

    curl https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe -o miniconda.exe
    start /wait "" miniconda.exe /S
    del miniconda.exe
    
  2. Create the environment:

    set ENV=env4ml
    conda update -y -n base -c defaults conda
    conda create -y -n %ENV% python=3.12
    conda activate %ENV%
    conda install -y pip
    pip install scikit-learn pandas matplotlib seaborn jupyterlab
    

No local install

If you would rather not touch your machine, Google Colab gives you Jupyter-style notebooks running on Google's GPUs and TPUs. It is the right starting point for one-off experiments, classroom assignments and short notebooks.

8. Historical and philosophical notes

Open Source — the backup generator

“AI is the new electricity.”

— Andrew Ng, Stanford Graduate School of Business, January 2017.

Andrew Ng's framing has been repeated so often that it now risks sounding obvious, but the trajectory it describes is real: AI is following the path electricity took a century ago — from a frontier technology, to a utility, to a quiet commodity that powers everything else. The analogy is useful here for a specific reason: electricity is also a textbook case of how to engineer for a serious dependency.

In any OECD country, a hospital is plugged into a power grid that is engineered, regulated, monitored and overwhelmingly reliable. It still keeps a diesel generator in the basement. Nobody runs the ICU off that generator on a normal Tuesday; it is there because, on the day the grid fails, "we trusted the utility" is not a defensible answer.

AI is settling into the same category of infrastructure as electricity, water and the road network. Hospitals, ministries, labs, schools and small businesses are coming to rely on it in ways that would be painful to undo. The important nuance — unlike the power grid — is that the commercial AI utilities are not run by the state. They are operated by a small number of private companies, in a small number of jurisdictions, each with its own pricing, policies and incident history.

The practical answer is the hospital's answer. Use a high-quality commercial AI when it is the best tool for the job, and keep an Open Source counterpart installed, tested and ready for the day a bill, a policy change, a rate limit or a geopolitical decision puts the commercial option out of reach. Open Source AI is, at the very least, the backup generator of the paid AI plant.

Even the most polished paid API goes down. Provider incidents, regional outages, revoked keys, sudden quota cuts, deprecated model snapshots, a vendor withdrawing from a country — none of these are hypothetical, and all of them have happened in production this year. Keeping an Open Source alternative on hand, ideally one you can run locally or on-prem, is not a philosophical stance; it is plain common sense — the same common sense that puts a generator in the basement of a hospital that has never lost power.

A pragmatic dual stack

A virtuous cycle, not a rivalry

Beyond the backup-generator argument, the two sides actively feed one another. Commercial labs push the frontier; Open Source catches up — often within months — and then advances it further with ideas the next proprietary release absorbs in turn. The lineage is hard to miss: TensorFlow and PyTorch released into the open by Google and Meta; the original Transformer paper on arXiv; Hugging Face and its Model Hub; llama.cpp running serious models on a laptop; Llama's open weights; DeepSeek-R1's reasoning recipes. Each one collapsed a cost curve or unlocked a technique the proprietary world then built on — and the other way around.

The whole intellectual adventure of modern AI — the papers, the benchmarks, the reproducible baselines, the worldwide community that reads and improves them — could not have happened inside a closed ecosystem. The field is too vast, too cross-disciplinary and moving too fast for any single lab to carry it alone. Without Open Source, there is no PyTorch to learn from, no arXiv preprint to reproduce on a Friday night, no Kaggle kernel to fork, no Hugging Face card to fine-tune — and no field as we know it.

The dual stack is therefore both operational hygiene and a quiet act of recognition. The generator runs once a month, the staff knows how to start it, and the day the grid fails the hospital keeps working. On every other day, the grid itself owes a great deal to the open code, open papers and open weights that made the whole electricity of AI possible in the first place.

Frameworks that mattered

Older frameworks and GPU abstraction layers such as Apache MXNet, PlaidML and DeepCL helped shape the evolution of deep-learning tooling, but I would no longer recommend starting a new project with them — MXNet in particular has been retired to the Apache Attic. They are worth knowing for context, not for green-fielding.

Why conda + pip

Throughout this page, the default has been conda + pip. The rationale is pragmatic:

Create the environment with conda, then install with either as needed. To export and recreate it:

conda list --export > requirements.txt
conda create --name ENVNAME --file requirements.txt

If something goes wrong and you need a clean slate:

cd ~
rm -rf miniconda*
rm -rf .conda*

Beginners looking for hands-on practice will find the free Kaggle courses a good place to start once the environment in section 1 is up and running.