Since December 2018 · Updated October 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.

Used every day 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. Section 1 is what we install on every fresh laptop in the lab. Section 2 is a table for the cases where that default does not fit. Sections 3 to 6 cover the libraries, the GPU question, the notebook and editor layer, and the road from a notebook to a demo you can show. Section 7 holds the long recipes, one per operating system, ready to paste. Section 8 says 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?

This is the whole page in four commands. The rest is detail around it.

You need Miniconda first. The commands below use conda, which comes with Miniconda (a small Anaconda). The install line depends on your operating system. Grab the one-liner for your machine from section 7. It covers Ubuntu, macOS (Apple Silicon) and 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.13
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, and the default install picks the right one for your machine.

Three cases need a detour. For an NVIDIA-CUDA-specific wheel, a Windows native path or the classroom setup without PyTorch, the per-OS recipes in section 7 cover each one. For a situation this default does not fit at all, the decision table in section 2 lists the alternatives. And to install nothing at all, Google Colab hands you a remote GPU notebook with NumPy, pandas, scikit-learn and PyTorch already in place.

Before you install: a few practical warnings

• Do not install ML packages globally. One environment per project saves you from pip conflicts that take a day to diagnose.
• Do not chase the newest Python blindly. Python 3.13 is the safe default for ML work today: every library in section 3 ships wheels for it. Python 3.14 exists and PyTorch already supports it, but a handful of smaller packages have not caught up, and ML libraries usually take a few months to fully support each release. Python 3.12 still works everywhere, so an environment you would rather not move can stay put. In production and teaching, compatibility matters more than novelty.
• GPU setup is where most installation pain happens. If a CPU-only install works, ship it first and add GPU support afterwards.
• For teaching, reproducibility beats peak performance. A slightly slower setup that every student can reproduce is worth more than a fast one that breaks for a third of the class.
• For deep learning at scale, CUDA is still the safest bet. Apple Silicon is excellent for prototyping; production-grade training still lands on NVIDIA.

2. Which setup matches my situation?

The default install in section 1 covers most readers. Your situation may be more specific. A particular GPU, a teaching constraint, a cloud-only workflow. Pick the row that matches and follow that path.

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, for pragmatic reasons rather than personal ones. Teams on R or Java can still ship through ONNX-R and DL4J; Rust is steadily gaining ground, see "Are we learning yet?".

Recommended toolboxes

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.

• Computer Vision tools: libraries, models, annotation, hosted platform (since 2000). Five pieces, from pixels to a hosted service:
  • Classical CV: OpenCV (2000). Image processing, geometric transforms, camera calibration, tracking. C++ core with Python bindings; still the right answer for everything that does not need a learned representation.
  • Object detection / instance segmentation: Detectron2 (Meta FAIR, 2019). Modular PyTorch toolkit for detection, segmentation, keypoint and panoptic tasks. Mature recipes, model zoo, and a straightforward training loop. It is the default serious-CV stack when you want full control over the architecture and training recipe. For a faster practical path, the Ultralytics YOLO line (pip install ultralytics) is the dominant ready-to-use stack. YOLO26 is the current release and widens the task list to detection, instance and semantic segmentation, depth estimation, classification, pose and oriented bounding boxes; YOLOv8, YOLO11 and YOLO12 are still shipped and still fine. AGPL-3.0, with a commercial license for closed-source use.
  • Annotation platform: CVAT (MIT-licensed) is the open-source reference for labelling image and video datasets: classification, detection, temporal labelling, segmentation, keypoints and OCR. The Community edition is free. Paired with an AI coding agent, you can stand up sophisticated annotation pipelines without writing all the tedious plumbing yourself.
  • Hosted CV platform + model hub: Roboflow (2020). Today's Roboflow is end-to-end: train, deploy and serve CV models, plus Roboflow Universe as a public hub of pre-trained models and datasets. They still ship Roboflow Annotate, but in 2026 their headline value is the training / deployment / inference stack, not annotation alone.
  • Self-supervised feature backbones: DINOv3 (Meta FAIR, 2025). Strong general-purpose image embeddings trained without labels; use as a frozen backbone for downstream tasks (classification, retrieval, segmentation) when you have few labels or want a robust feature space without retraining.
• Classical ML (since 2007). scikit-learn. The standard Python library for classification, regression, clustering and model selection. Stable API, good defaults, excellent docs. Start here unless your problem clearly needs deep learning.
• Deep learning (since 2015). Today I would usually start with PyTorch (2016): widely used in research and practice, large ecosystem, most new architectures land here first. TensorFlow (2015) is still important for three things. Its ecosystem, its production tooling, and its mobile or edge deployment path through TF Lite and LiteRT.
• Higher-level deep-learning wrappers (since 2015). Keras 3 (2015; now multi-backend, running on TensorFlow, JAX or PyTorch, with OpenVINO for inference) is the high-level API to consider when you want one Python interface across backends. PyTorch Lightning (2019) removes the training-loop boilerplate and gives you distributed training and checkpointing for free.
• NLP + LLM tools: classical NLP, transformer models, local inference, retrieval, evaluation (since 2015). Five pieces, from tokenisation up to evaluation:
  • Classical NLP + word embeddings: spaCy (2015) for industrial-strength tokenization, NER, dependency parsing and POS tagging. fastText (Meta, 2016) for very fast word embeddings and multilingual text classification: C++ core, Python bindings, still a strong low-cost baseline against transformer models.
  • Transformer models + embeddings: Hugging Face Transformers (2018) for pre-trained encoders, decoders and seq2seq; sentence-transformers (2019) for dense semantic embeddings and retrieval. See also the standalone Hugging Face bullet below.
  • Local LLM inference: Ollama (2023) is the easiest local-first daemon: it wraps llama.cpp for quantised inference on CPU, Apple Silicon (MPS / MLX) or CUDA. For production-scale serving with paged attention, continuous batching and OpenAI-API compatibility, use vLLM (2023). For model choice, size decides. In the small range, when the model has to fit on a laptop, a phone or an edge device, the Qwen family is usually the strongest. At the larger end, with a real GPU under it, Gemma tends to be the more reliable pick.
  • Retrieval + RAG orchestration: LangChain or LlamaIndex (both 2022) to compose retrievers, prompts and tool calls. Pair with a vector store: FAISS (Meta) gives you the standard in-process ANN index. When memory matters, use turbovec (2026; Rust core with Python bindings, built on Google Research's TurboQuant). It compresses float32 embeddings to 2 or 4 bits and fits about 10 M vectors in 4 GB while keeping competitive recall, with no separate training step. My preferred ANN index for local RAG. Qdrant or Chroma when you need a separate service.
  • LLM evaluation: DeepEval (2023) for assertion-style tests with LLM-as-judge in a Pytest-shaped runner; Ragas (2023) for RAG-specific metrics (context relevance, faithfulness, answer correctness).
• Fairness + explainability + causality: bias metrics, local explanations, counterfactuals, causal effects, audit (since 2016). Six pieces. Run them before the model ships, not after a regulator asks:
  • Fairness metrics + mitigation: Fairlearn (Microsoft, 2018) ships demographic parity, equalized odds and a catalog of mitigation algorithms (post-processing, reductions).
  • Local explanations: SHAP (2017) unifies Shapley-value feature attributions across model families and is the usual answer for tabular and tree models. Shapash (MAIF, 2020) sits on top of SHAP and LIME with a business-readable layer: feature labels, a built-in webapp for non-ML stakeholders, and one-call export of individual-prediction reports. Pick it when the audience for the explanation is not the ML team. LIME (2016) is the older perturbation-based approach, still useful as a sanity check.
  • Counterfactual explanations: FACET (BCG X, 2020) for supervised-learning explainability plus counterfactual simulation on top of scikit-learn. DiCE (Microsoft, 2020) generates diverse counterfactuals: "what minimal change would flip this prediction?"
  • Bias auditing pipeline: Aequitas (CMU DSSG, 2018) wraps the metric zoo into an end-to-end audit with reports per protected group, useful when you need to show your work to a non-ML reviewer.
  • Deep-net attribution + interactive what-if: Captum (Meta / PyTorch, 2019) for integrated gradients and other attribution methods on neural nets. What-If Tool (Google PAIR, 2018) is the TensorBoard / Colab plugin for tweaking inputs interactively.
  • Causal inference: PyWhy (open-source ecosystem, 2022; spun out of Microsoft Research). Its core library DoWhy ships a four-step pipeline (model → identify → estimate → refute) for answering "does X cause Y?" rather than "can we predict Y from X?". EconML handles heterogeneous treatment effects when the answer depends on the subgroup. Causal counterfactuals are the sibling of the FACET / DiCE counterfactuals above. Instead of "what input change would flip the prediction?" they ask "what intervention would change the outcome?"
• Tabular-data preprocessing (since 2017). skrub (originally dirty_cat, renamed in 2024; from the Probabl / Inria scikit-learn family). It turns messy real-world tables into scikit-learn-ready features. Fuzzy joins on dirty string keys. Encoders for high-cardinality categories, GapEncoder, MinHashEncoder and TableVectorizer. And a one-call tabular_pipeline() baseline, renamed from tabular_learner(), so older snippets you find online need the new name. Use it whenever your CSV needs cleaning before it can reach a scikit-learn pipeline.
• Tabular foundation models (since 2022). An unexpected result of the foundation-model wave: pre-trained transformers now match or beat well-tuned gradient-boosted trees on small-to-mid tables, with zero training on your data. Two of them matter today. TabPFN comes from the Hutter lab, NeurIPS 2022, with v2 in Nature, 2025. TabICL comes from Inria SODA, first published at ICML 2025; v2, presented at ICML 2026, is both more accurate and the first to ship a regressor alongside the classifier. Both read your training CSV as examples and predict the test rows in a single forward pass. No gradient steps, no hyperparameter search. The "is XGBoost still king on tabular?" answer is finally shifting; try one before reaching for a stack you have to train yourself.
• Pre-trained models for CV / NLP / Speech (since 2018). Hugging Face. Model hub plus the transformers, diffusers and datasets libraries, the distribution layer for open-weights models. A one-line from_pretrained() is the modern equivalent of pip install.
• AI testing tools: model scans, LLM unit tests, RAG eval, red-team, data validation (since 2022). Five pieces. A held-out accuracy number tests one thing; these test the rest:
  • Model and agent scans: Giskard (2022; open source on GitHub plus a hosted hub) is the nearest thing to a one-call "what's wrong with this model?" check: robustness, performance issues, hallucination, prompt injection and bias. Version 3 moved its centre of gravity from tabular and NLP models to evaluation, red-teaming and test generation for agentic systems, which is where the hard failures now are.
  • LLM unit testing: DeepEval (2023, open source on GitHub) wraps LLM-as-judge metrics in a Pytest-shaped runner: assertion-style tests for hallucination, answer relevancy, summarisation quality. Drop alongside your regular test suite.
  • RAG-specific metrics: Ragas (2023) for context relevance, faithfulness and answer correctness on retrieval-augmented pipelines. Pair with DeepEval when the system uses both retrieval and free generation.
  • LLM red-team + safety: PyRIT (Microsoft, 2024) is the Python Risk Identification Tool for automated red-teaming against generative AI. garak (NVIDIA, 2023) is the LLM vulnerability scanner: prompt injection, jailbreaks, data leakage, hallucination probes.
  • Data + schema validation: Great Expectations (2017) and Pandera (2019) check the data before it reaches the model. You cannot test a model whose inputs you cannot audit, so put these upstream of it.
• Machine Learning project tracking (since 2024). Skore (by Probabl, the scikit-learn company). Sits on top of scikit-learn to give you opinionated evaluation, model comparison and a project-level dashboard. Use it the moment you have more than one model worth comparing.

AI helpers

Seventeen BSD-3-Clause Python libraries Warith maintains with Mohamed Chelali and Bachir Zerroug, online since April 2024. The full index lives at deraison.ai/ai-helpers. Each one wraps a specific corner of the AI / media stack so you do not re-implement the same plumbing in every project. Install only the corner you need; each package pulls in os-helper on its own.

Two things make them worth a look beyond the convenience. Every helper exposes the same five surfaces: a Python API, two CLIs (argparse and click), a FastAPI HTTP server, an MCP tool set mounted on that same app, and an installable Claude Code / OpenCode skill. The MCP surface is not a second implementation, it is the same FastAPI routes mounted at /mcp, so the two cannot drift apart. And the default is local-first: audio, video, capture, vocal, md2star and wallet run entirely on your machine, on ffmpeg, whisper.cpp, pyannote and a local Ollama model. The two that move your data, bucket-helper and sftp-helper, say so out loud: that is their job.

Core. os-helper: cross-platform file handling, hashing, config, timing. The foundation every other helper builds on.

Audio and voice. audio-helper loads, converts, source-separates (optional Demucs), splits and concatenates audio. vocal-helper turns audio into diarized, transcribed utterances on Silero VAD, whisper.cpp and pyannote, streaming or batch, with an optional rolling LLM summary. speaker-helper is the other direction, text to speech in your own process rather than behind a server, with the timed track that lets a page follow along word by word. discussion-helper closes the loop into a spoken conversation that stops the moment you interrupt it.

Video and capture. video-helper: multi-backend frame extraction (VidGear, PyAV, ffmpeg pipe), conversion and subtitle formats. capture-helper: live camera and microphone capture, plus a browser configurator for multi-source scenes.

Media acquisition. youtube-helper downloads video, audio and thumbnails from YouTube, Vimeo, DailyMotion, SoundCloud and Twitch via yt-dlp. podcast-helper is the universal version of the same promise, URL in and PCM out, from files, direct URLs and RSS or Atom feeds, with Shannon-correct resampling.

Storage and transfer. bucket-helper for S3 and anything S3-compatible (MinIO, Backblaze B2, DigitalOcean Spaces, Cloudflare R2, Wasabi). sftp-helper for SFTP, with strict host-key verification.

Documents and cache. md2star bridges Markdown to DOCX, PPTX and PDF on Pandoc, with branded templates, Mermaid rendering and bibliographies, and a twin command that walks the path backwards from a PDF to editable Markdown. wallet-helper makes sure you never run the same heavy call twice: content-addressed memoization keyed on a file's bytes rather than on its path, plus single-flight so concurrent identical calls collapse into one.

Deciding instead of guessing. Three of them answer a question you would otherwise answer by habit. best-engine-ai-helper measures the machine it runs on, Apple unified memory or NVIDIA VRAM or plain RAM, then picks and pulls the best local LLM that fits a safety headroom. ann-router is the same idea for vector search: describe the problem in measured terms (dataset size, dimensionality, recall target, memory budget) and it selects and justifies a backend among exact search, turbovec, HNSW, FAISS, Annoy, Qdrant and pgvector. elbow-helper answers the harder version of the elbow question: not "where is the knee" (an algorithm asked that always returns something, even on pure noise) but "is there one at all", with an explicit abstention.

Comparing instead of asserting. standpoint turns a comparison table into a labelled 2D positioning map plus a YAML of every coordinate, so the placement is auditable rather than hand-drawn.

Five of them have a Rust rewrite on crates.io rather than PyPI, for the cases where a Python runtime is not available: audio-helper-rs, capture-helper-rs, podcast-helper-rs, youtube-helper-rs and md2star-rs. They trade surface for footprint and are not drop-in replacements.

4. GPU choices: NVIDIA CUDA vs Apple Silicon

Two hardware paths dominate practical ML in 2026, and they cover different jobs. 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.

• Best for: deep learning at scale, large-batch training, production inference.
• Install via the official PyTorch selector for the right CUDA wheel.
• Free research GPUs: the NVIDIA Academic Grant Program.

Apple Silicon (M-series)

A serious option for local ML work today. Unified memory and quiet hardware make it comfortable for experimentation, prototyping, teaching and many small-to-medium workflows. It is not a drop-in replacement for CUDA at the high end.

• Best for: local development, prototyping, teaching, edge experiments.
• PyTorch via the Metal Performance Shaders backend (mps device).
• Apple's own MLX for NumPy-style research on Apple Silicon (see also mlx-examples).

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. Make the move once it has paid for itself, and not before.

5. Notebooks, IDEs and AI coding agents

Where you write the code matters almost as much as the libraries underneath. Three layers get touched every day. Notebooks, to explore. Editors, for real work. And AI coding agents, which now sit on top of both.

Notebooks

• JupyterLab: the default in-browser notebook for exploration, demos and teaching. Install with pip install jupyterlab, start with jupyter lab.
• Marimo (since 2023). A reactive notebook stored as a plain .py file (diff-friendly, no JSON, version-control friendly). Cells form a dataflow graph: change a value upstream and every downstream cell re-runs automatically, with no hidden state and no "out-of-order Jupyter" debugging sessions. Built-in UI widgets (mo.ui.slider, mo.ui.dropdown, mo.ui.table) turn a notebook into a small reactive app with marimo run notebook.py. Use it as a modern Jupyter replacement when you want reproducibility, code review and lightweight ML demos in the same artefact.
• Google Colab: a notebook that runs on Google's GPUs and TPUs instead of yours. Use it for a few hours of GPU, or for a classroom where every student must get the same environment.

Editors

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

• Cursor (Anysphere, 2023) is the original AI-first VS Code fork. Deep inline completions, and an agent mode that runs commands. It is the editor most ML teams compare everything else against.
• Google Antigravity (2025) is Google's agent-first VS Code fork. Up to five agents run in parallel under a Manager view, and it embeds a Chrome view so you can look at the interface it just built. It is deliberately model-agnostic: Gemini by default, with Anthropic and open-weight models selectable per agent. We do not name versions here on purpose, because that list turns over every few months.
• The open-source equivalent in the same VS Code family is Cline (Apache-2 extension; bring-your-own-key for any provider, including local Ollama; top of the open-source SWE-bench leaderboard).

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.

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

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. One engineer understands what the compiler, or the model, actually produced. That engineer is still the one who can debug it, optimize 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 lesson is short. Treat an AI coding agent as the next compiler. Write what you want clearly, then read what comes back 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.

Both agents read the same skills format. A skill is a folder holding a SKILL.md. That file teaches the agent one job, and it loads only when your prompt matches. The suite we use for everything that ends up on a screen, from a demo page to a figure in a paper, is Sprezzature, covered in section 6.

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 one turns Python code into a usable web form in minutes, and covers the common case very well. There is a price. The result looks like a Streamlit, Gradio or Taipy app, because their CSS is hard to override cleanly. Apps built with them end up looking alike.

When you already have a CLI: Sprezzature

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?". Sprezzature is one answer. It is a suite of nine Open Source skills for Claude Code and OpenCode. It locks the agent onto one frontend stack, vanilla JavaScript with Tailwind CSS and the three Roboto families, and hands it a design system already chosen.

Ask the agent to "wrap this CLI in a GUI". Out comes a single page: index.html, app.js and a Tailwind config. Every argparse or click flag becomes the right form control, and the output of the CLI streams into a log panel. No framework to be locked into, no Python runtime, no "Gradio look", just plain HTML you can edit.

The nine skills

Install only the ones you need. sprezzature-ui carries the stack rules and the design tokens; the others inherit them.

There used to be a tenth, sprezzature-vision. It folded into sprezzature-accessibility, which is the right place for it: the lint that finds the missing alt is also the thing that should be able to write it.

Install with Claude Code

VERSION=$(curl -fsSL https://api.github.com/repos/warith-harchaoui/sprezzature/releases/latest \
  | sed -n 's/.*"tag_name": *"v\([^"]*\)".*/\1/p')
curl -L https://github.com/warith-harchaoui/sprezzature/releases/download/v${VERSION}/sprezzature-skills-${VERSION}.tar.gz | tar xz

mkdir -p ~/.claude/skills
cp -r sprezzature-ui sprezzature-cli-gui sprezzature-figures ~/.claude/skills/

Or OpenCode

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

Documentation: sprezzature.ai. Repo: github.com/warith-harchaoui/sprezzature.

Why this matters for ML practitioners

• Your CLI keeps owning execution. Sprezzature only emits the UI shell and a thin HTTP+SSE adapter on top of your existing CLI. You do not rewrite your training loop, your inference script or your evaluation harness.
• The output looks like your project, not the toolkit's. Sprezzature emits plain Tailwind that you can read, audit and adjust.
• Every skill makes, then audits. Generation is paired with a deterministic check against the stated rules: the accessibility lint, the contrast audit, the Laws of UX auditor. The check is a script with an exit code, not a second opinion from the model.
• Somebody looks at the figure. You can proofread a sentence by reading it back. You cannot do that with a chart, because whether it is right lives in the pixels rather than in the code. So the Ralph Eyeball Loop renders the figure to an image, has the agent (or an offline vision model) look at it, then fixes the source and renders again. It catches the label cut off at the edge and the legend that slid off the canvas, which no code check will ever see. For a lab that ships plots in papers and slides, this is the part that saves the most time.
• The models can stay on your machine. Alt text and captions route through a local Ollama or a local whisper.cpp when you ask for it, so unpublished data never leaves the laptop.
• Accessibility and translation come with the markup. Focus rings, dark-mode peers and reduced-motion guards are emitted by default. Alt text, captions, the contrast audit and a strings-to-YAML pass for translation each have their own skill, so none of it is a follow-up sprint.
• You can skip the agent entirely. Nine of the deterministic tools also ship as pip packages (sprezzature-figures, sprezzature-colors, sprezzature-accessibility, sprezzature-cli-gui, sprezzature-ux-laws, sprezzature-audio, sprezzature-maps, sprezzature-publish, sprezzature-ui), usable as a Python library, an HTTP API or MCP tools.
• It composes with the rest of your stack. Drop the emitted HTML into Tauri for a desktop app, into FastAPI for a hosted demo, or behind any reverse proxy.

When the demo needs to ship

Once an HTML page drives a CLI, packaging is easy. Tauri for a desktop app. FastAPI for a hosted demo with a clean HTTP boundary. An ONNX export when the model has to leave Python entirely. Each one is a small added step, not a rewrite, because the CLI, the model and the interface 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. To carry a model across languages, use ONNX. It is both a file format and a runtime, maintained 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, pybind11 gives the best experience, and Meta used it for fastText. Cython remains a solid option, with scikit-learn as 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 for three cases. Setting up a fresh machine. Needing NVIDIA or CUDA drivers. Wanting a Linux-like environment on Windows. Throughout, the environment is named env4ml and the Python version is 3.13, the newest release the whole stack in section 3 ships wheels for. Swap in 3.12 if a package you depend on has not followed.

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.13
   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. Take the cuXXX suffix from the selector, not from this page. Each CUDA channel is frozen once PyTorch stops building for it, so a stale suffix silently installs an old PyTorch rather than failing. As of October 2026 the newest channel is cu130:

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

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.13
   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 development environment close to what cloud and server machines run. The same installation commands then work in three places: your laptop, a CI runner and a remote GPU box.

Recommended path: WSL2

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.13
   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 at all, Google Colab needs no installation: open a notebook in the browser and the GPU is already attached. Good for a one-off experiment, a homework assignment or a short demo.

8. Historical and philosophical notes

Open Source: the backup generator

The line has been repeated so often that it sounds obvious. The path it describes is real. Electricity went from frontier technology, to utility, to something nobody thinks about, and AI is walking the same road. The comparison is useful here for one reason. Electricity is also the textbook case of how to depend on something safely.

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 intensive care unit off that generator on a normal Tuesday. It is there for the day the grid fails, because "we trusted the utility" is not an answer anyone can defend.

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 difference with 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. Keep an Open Source counterpart installed and tested. One day a bill, a policy change, a rate limit or a political decision will put 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 have happened in production this year. So keeping an Open Source alternative on hand is plain common sense, ideally one you can run locally or on your own servers. It is the same common sense that puts a generator in the basement of a hospital that has never lost power.

A pragmatic dual stack

• Commercial side: Claude, ChatGPT, Gemini, Mistral: frontier capability, hosted inference, SLAs.
• Open Source side: open-weight families from Meta Llama, Google Gemma, Qwen, Mistral and DeepSeek, runnable locally via Ollama, llama.cpp or vLLM.
• Coding agent: the same pattern, one layer up. Claude Code for daily work, OpenCode in the basement. OpenCode drives the same skills with a local model, for the day the upstream API is unreachable or off-limits.

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, 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.

Modern AI could not have been built inside a closed ecosystem. Its papers, its benchmarks, its reproducible baselines and the worldwide community that reads and improves them all needed the open door. The field is too large, too cross-disciplinary and moving too fast for one lab to carry 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. There is no field.

So the dual stack is two things at once. It is sound practice: the generator runs once a month, the staff knows how to start it, and the day the grid fails the hospital keeps working. And it is a debt acknowledged. On every other day, the grid itself runs on open code, open papers and open weights.

Frameworks that mattered

Older frameworks and GPU layers such as Apache MXNet, PlaidML and DeepCL shaped the tooling we use today. I would no longer start a new project with any of 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:

• conda manages isolated environments and Python versions, and handles compiled scientific dependencies cleanly across platforms.
• pip reaches the rest of the Python package universe, including ML libraries that ship faster on PyPI than on conda channels.

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.