37 posts tagged with "Python"

A run is one execution of your code that MLflow records: its settings, results and files. Everything you log goes into the active run, so how you start and end runs decides where your data lands. This guide starts runs four ways, names them, checks their status, and shows what MLflow does when your code fails halfway, with real output from MLflow 3.18.0.

An MLflow experiment is a folder for related runs: one per project, or one per question you're trying to answer. Every run belongs to exactly one experiment. This guide creates experiments two ways, reads their ID and artifact location, shows the error you get for a duplicate name, and finds them in the UI, with real output from MLflow 3.18.0.

The tracking URI tells your code where MLflow records go. Get it wrong and nothing fails: MLflow quietly writes your runs somewhere else, and your UI stays empty. This guide shows the two ways to set it, which one wins, how to check it, and exactly what MLflow 3.18 does when you don't set it, with real output.

Since version 3.2.0, open-source MLflow collects anonymous usage data by default: which features you use, your MLflow and Python versions, your operating system. It doesn't collect your data, parameters or file names, but you may still want it off. One environment variable turns it off for your scripts, the tracking server and the UI. This guide sets it on macOS, Linux and Windows, and proves it worked.

The MLflow tracking server listens on port 5000 unless you tell it otherwise. That port is often taken: on a Mac, the AirPlay Receiver already holds it, and other programs like it too. One option moves MLflow to any free port. This guide changes the port, checks what's using a port, and keeps your code pointed at the right address.

The MLflow tracking server is the place your training runs go: a small web server that stores every run and shows them in the MLflow UI. You don't need a cloud account or a database server to run one; MLflow 3.18 brings everything, including a SQLite database. This guide starts a server on your own computer, explains every line it prints, checks that it's ready, and stops it safely.

MLflow installs like any Python package, but it brings a lot with it: a web server, a database layer and the most common data science libraries. Installing it into a uv project keeps all of that inside the project and records the exact versions. This guide installs MLflow 3.18.0, checks it, and explains which of MLflow's three packages you need.

Hard-coding a port, a database address or a password into your code means editing the code for every computer it runs on. pydantic-settings reads those values from environment variables and a .env file instead, checks them, and gives your code typed values. This guide explains the syntax first, then builds the settings of a small demo app and shows, with real output, which source wins and what happens when a value is wrong.

Before you follow a guide, report a bug or upgrade, you need to know exactly which version of a package your project runs. In a uv project the answer is in the project's own environment, not in your computer's Python. This guide gives the syntax of four ways to read it first, then uses each one on a small hello-world project, with real output from uv 0.13.8.

You added a package with uv, ran your script with python3, and got ModuleNotFoundError. The package is installed, just not in the Python you started. uv run runs everything inside the project's own environment, and brings that environment up to date first. This guide explains the command's syntax first, then runs a small script, a project command and a tool in a hello-world project, with real output from uv 0.13.8.