Skip to content

mise: Polyglot Runtime and Tool Version Manager

by Tim Hopper · Markdown
Virtual Environments Coming from Another Language

mise (pronounced “meez,” formerly named rtx) is a cross-platform command-line tool that manages multiple language runtimes, environment variables, and project tasks from a single manifest. It installs and switches versions of Python, Node.js, Rust, Go, Ruby, and more than a thousand other tools, activating the correct versions automatically as the shell moves between directories.

When to use mise

mise fits polyglot projects that need more than one language runtime pinned together. A repository that combines a Python backend, a Node.js frontend, and a Terraform deployment can declare all three versions in one mise.toml file. Teams already running asdf use mise as a faster drop-in that reads the same .tool-versions files.

For a Python-only project, uv covers interpreter installation, virtual environments, and dependency management in one binary. mise handles the interpreter but delegates packaging to a separate tool. See How it relates to uv for the division of labor.

Installation 

curl https://mise.run | sh

This installs the mise binary to ~/.local/bin. Activate it in the shell startup file so version switching happens per directory:

echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc

Substitute zsh or fish for bash as appropriate.

Installing Python

mise downloads precompiled Python binaries from python-build-standalone by default, the same source uv uses. This makes installation faster than compiling from source.

# Install and set Python 3.13 as the global default
mise use -g python@3.13

# Pin Python for the current project (writes to mise.toml)
mise use python@3.13

# Install a version without setting it active
mise install python@3.12

The python.compile setting controls the install method. Left undefined, mise uses a precompiled binary when one exists for the platform and compiles otherwise. Setting it to true (or the MISE_PYTHON_COMPILE environment variable) forces compilation with python-build, the same builder pyenv uses; false forces precompiled binaries only.

Key Features

  • Polyglot version management. A single mise.toml pins versions for Python, Node.js, Rust, Go, Ruby, and over a thousand other tools, switching them automatically per directory.
  • Precompiled Python by default. Downloads python-build-standalone binaries, with optional source compilation via python-build for platforms or flavors without a prebuilt binary.
  • Environment variable management. Loads project-specific environment variables from mise.toml, .env files, and shell commands when entering a directory.
  • Task runner. Defines build, test, lint, and deploy commands in mise.toml alongside the tools and env vars they require, run with mise run.
  • PATH activation over shims. mise activate updates PATH on each prompt rather than routing every call through shim scripts, adding roughly 5ms at prompt load instead of per-command overhead. A shims mode is available for CI, IDEs, and scripts.
  • asdf compatibility. Reads asdf’s .tool-versions files and can use asdf plugins through its asdf backend, easing migration from asdf.
  • Idiomatic version files. Recognizes .python-version, .node-version, .nvmrc, and similar single-language version files in addition to mise.toml.
  • Automatic virtualenv activation. The _.python.venv config option creates and activates a virtual environment on directory entry; python.uv_venv_auto integrates with uv-managed projects that have a uv.lock.

Configuration

mise reads its manifest from mise.toml in the project directory, with a global config at ~/.config/mise/config.toml. Tools are declared under a [tools] table:

[tools]
python = "3.13"
node = "24"

[env]
DATABASE_URL = "postgres://localhost/dev"

[tasks.test]
run = "pytest"

A mise.local.toml file, ignored by version control, overrides shared settings for a single machine.

Pros

  • Manages every language runtime a polyglot project needs from one manifest and one binary.
  • Precompiled Python binaries install in seconds without C build tools.
  • PATH-based activation avoids the per-call latency of shim-based managers.
  • Reads existing asdf .tool-versions files and single-language version files, so adoption rarely requires rewriting configuration.
  • Bundles environment variables and a task runner, reducing the number of separate tools a project depends on.

Cons

  • Does not manage Python packages or dependencies; it must be paired with uv, pip, or another packaging tool.
  • The broad scope (runtimes, env vars, tasks) is more surface area than a reader who only needs Python interpreter management requires.
  • asdf plugins run arbitrary shell code with minimal vendor oversight; mise mitigates this with native signature verification but the plugin risk remains for tools sourced through the asdf backend.
  • Shell activation must be configured for automatic per-directory switching, an extra setup step compared with a self-contained binary.

How it relates to uv

mise and uv overlap on Python interpreter installation and both pull from python-build-standalone, but they occupy different scopes.

mise manages the interpreter and other language runtimes across a polyglot project. uv manages the Python interpreter plus virtual environments, dependency resolution, and packaging for a single Python project. mise does not resolve or install Python dependencies; uv does not manage Node.js, Rust, or Go.

The two work together: mise pins the language runtimes a repository needs, and uv drives the Python project and its dependencies inside that environment. mise’s python.uv_venv_auto option activates a uv-managed virtual environment automatically when entering a project with a uv.lock. For a Python-only project, uv alone is the simpler choice. For an interpreter-only need shared with other languages, mise replaces the combination of pyenv, nvm, and rbenv.

Related Handbook Pages

Learn More

Last updated on
Material for MkDocsMkDocs