Understanding uv Workspaces

The official uv website explains workspaces very clearly:

Inspired by Cargo, a uv workspace is a collection of one or more Python packages (workspace members) managed together in a single repo. Each package has its own pyproject.toml, but the workspace shares one lockfile, keeping dependencies consistent across apps and libraries. Commands like uv lock operate on the whole workspace, while uv run and uv sync default to the workspace root but can target a specific member via --package ¹.

Most of the time when we say “my model learned something,” what it actually learned is a bunch of very smart correlations. If users who click A also tend to click B, or if certain pixels tend to appear together in cat photos, our models will happily latch onto those patterns and exploit them. That’s powerful—and often enough for prediction—but it’s not the same as understanding what would happen if we actually changed something in the world: raised a price, changed a policy, or shipped a new feature.

This is part of my Docker Basics series — introductory guides to help you get started with Docker, learn key concepts, and build your skills step by step.

• Part 1: Understanding Container
• Part 2: Basic Commands
• Part 3: Dockerfile
• Part 4: Networks

Docker Fundamentals (Part 1)

Software systems frequently exhibit environment-dependent behavior: dependency versions drift, filesystem paths diverge, and minor operating-system differences produce major failures. Containerization addresses this by packaging an application together with its runtime dependencies so that a single artifact executes consistently across development laptops, continuous-integration pipelines, and production clusters. Formally: same package $\rightarrow$ same behavior across environments.

This is part of my Docker Basics series — introductory guides to help you get started with Docker, learn key concepts, and build your skills step by step.

• Part 1: Understanding Container
• Part 2: Basic Commands
• Part 3: Dockerfile
• Part 4: Networks

Common Commands

This is a no-frills cheat sheet for the Docker commands you’ll reach for most of the time, with tiny runnable examples you can copy/paste.

This is part of my Docker Basics series — introductory guides to help you get started with Docker, learn key concepts, and build your skills step by step.

• Part 1: Understanding Container
• Part 2: Basic Commands
• Part 3: Dockerfile
• Part 4: Networks

Basic Commands

A Dockerfile is essentially a text file with a predetermined structure that contains a set of instructions for building a Docker image. The instructions in the Dockerfile specify what base image to start with (for example, Ubuntu 20.04), what software to install, and how to configure the image. The purpose of a Dockerfile is to automate the process of building a Docker image so that the image can be easily reproduced and distributed.

This is part of my Docker Basics series — introductory guides to help you get started with Docker, learn key concepts, and build your skills step by step.

• Part 1: Understanding Container
• Part 2: Basic Commands
• Part 3: Dockerfile
• Part 4: Networks

Docker Networking

Docker offers four built-in network drivers: none, bridge, host, and overlay.

• Bridge (default): Creates an isolated, software-defined network. Containers on the same bridge get private IPs and can communicate with each other, while anything outside can’t reach them unless you explicitly publish ports.
• Host: Removes the isolation layer and uses the host’s network stack directly. The container shares the host’s IP address and network interfaces.
• Overlay: Builds a virtual network that spans multiple Docker hosts, so containers on different machines can talk as if they’re on the same one—handy for Docker Swarm.
• None: Disables networking (other than loopback) for the container.

You can create and manage custom networks of any of these types with the Docker CLI.