Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/cachix/devenv/llms.txt

Use this file to discover all available pages before exploring further.

Instead of creating and maintaining a devenv.nix file, you can create ad-hoc developer environments directly from the command line using the --option flag. This is ideal for quick experiments, one-off tasks, or testing a tool before committing to a full project configuration.

​
Basic Usage

Pass any devenv configuration option with --option, specifying the inferred Nix type as a suffix. For example, to spin up a Python 3.10 shell without any config file: 
$ devenv --option languages.python.enable:bool true \
         --option languages.python.version:string "3.10" \
         shell

​
Option Types

Every --option value requires a type annotation after the option name:
SuffixTypeExample value
:stringString"3.10"
:intInteger8080
:floatFloat3.14
:boolBooleantrue / false
:pathFile path (relative)./mydir
:pkgSingle nixpkgs packageripgrep
:pkgsSpace-separated list of packages"ncdu git ripgrep"

​
Installing Packages

Use the special :pkgs type with the packages option to install tools from nixpkgs on the fly: 
$ devenv --option packages:pkgs "ncdu git ripgrep" shell
This creates an environment with ncdu, git, and ripgrep available — no devenv.nix required.

​
Enabling Language Toolchains

Enable any language module and configure it inline. The following example activates the Rust toolchain on the nightly channel: 
$ devenv --option languages.rust.enable:bool true \
         --option languages.rust.channel:string nightly \
         shell

​
Running Ad-hoc Commands

You can run a specific command inside the ad-hoc environment by passing it after shell: 
$ devenv --option languages.elixir.enable:bool true shell iex
This launches an Elixir interactive shell (iex) immediately after the environment is ready — no separate devenv shell step needed.

​
Replacing vs. Appending Lists

List types like :pkgs append to existing values by default. Use a ! suffix on the type to replace the entire list instead: 
$ devenv -O packages:pkgs! "ncdu git" shell
This discards any packages already defined in devenv.nix and replaces the list with only ncdu and git.

​
Using a Remote Configuration with --from

The --from flag lets you use a devenv.nix stored in another location — a remote GitHub repository or a local path — without needing any config files in the current directory: 
$ devenv shell --from github:myorg/devenv-configs?dir=rust-web
$ devenv shell --from path:../shared-config
--from accepts any Nix flake input reference. It works with devenv shell, devenv test, and devenv build. Currently --from only supports projects that use devenv.nix alone; projects that also rely on devenv.yaml for extra inputs are not yet supported.

​
Combining with an Existing devenv.nix

When run inside a project that already has a devenv.nix, values passed via --option override the matching settings in the file. The rest of the configuration is inherited unchanged, making it easy to test variations without editing the file.
The -O short flag is an alias for --option, handy when typing multiple flags at once.

​
Use Cases

Ad-hoc environments shine in situations such as:
Test a language or tool before adding it to your project’s devenv.nix. For example, try out a newer Python version with a single command before committing.
Run a utility that isn’t part of your normal environment — ncdu to analyse disk usage, jq to process JSON — without permanently changing the project config.
Combine with shell scripting to iterate over a set of options, for example testing the same code against multiple Python versions:
for version in "3.10" "3.11" "3.12"; do
  devenv --option languages.python.enable:bool true \
         --option languages.python.version:string "$version" \
         shell python -c "import sys; print(sys.version)"
done

​
Limitations

Ad-hoc environments are best for simple configurations. For complex setups — multiple services, custom scripts, Git hooks — a devenv.nix file provides better readability and reproducibility. Some deeply nested options may also be harder to express on the command line.

Build docs developers (and LLMs) love

Get started for freeTalk to us