.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Everything useful you do with Miniconda happens inside environments. The installer ships little beyond conda and one Python on purpose: the intended workflow is an isolated environment per project, each with its own pinned interpreter, so one project's dependencies never leak into the next. This guide runs through that lifecycle on a standard install in ~/miniconda3. No install yet? The guide to install Miniconda on Ubuntu gets you there first.
Create an environment with conda create
Every project starts here:
conda create -n myproject python=3.12-n names the environment, and the python=3.12 part shouldn't be treated as optional. A bare conda create -n myproject produces an environment with no Python in it at all, which catches nearly everyone once. The pin also carries the reproducibility: six months on, on another machine, the same command builds the same interpreter instead of whatever was newest that day. (Sometimes the pin points backward, python=3.11 for a dependency that hasn't caught up, and that situation comes up more often than library changelogs admit.)
Conda prints its plan and asks for confirmation before doing anything. -y skips the prompt, which scripts want and interactive fingers eventually regret.
Activate and deactivate the environment
Nothing you created is in use until you activate it:
conda activate myprojectThe prompt prefix changes from (base) to (myproject), and which python now answers with ~/miniconda3/envs/myproject/bin/python. I've gotten into the habit of running that path check before any pip install, just to confirm I'm where I think I am. conda deactivate drops you back to base when you're done.
