Lab 05 — Mamba and your first project env

Goal

Install mamba (the fast drop-in replacement for conda) on Unity, create a per-project Python environment with the scientific libraries you’ll use for the rest of this course, and export a portable environment.yml that you (or your labmates) can use to recreate the env on any machine.

By the end of this lab, you have mamba activate eslab working in any fresh shell, with NumPy, pandas, matplotlib, scikit-learn, and Jupyter installed and ready.

Reading

Budget ~30 minutes for the reading.

Learning objectives

  1. Install Miniforge3 (which ships with mamba) into your Unity home directory.
  2. Create a per-project mamba environment and activate/deactivate it.
  3. Install scientific packages with mamba install; inspect with mamba list.
  4. Export environment.yml in both naive and --from-history forms and explain the difference.
  5. Register your environment as a Jupyter kernel for use in Lab 7.

Setup / prerequisites

  • Labs 01–04 complete — you should be working from VS Code’s integrated terminal on Unity.
  • ~5 GB of free space in your home directory for the Miniforge install.

Tasks

1. Download and run the Miniforge installer (10 min)

From your Unity home directory:

cd ~
wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh
ls -lh Miniforge3-Linux-x86_64.sh         # confirm download worked, should be ~80 MB

bash Miniforge3-Linux-x86_64.sh

The installer asks three questions:

  1. License — accept? Type yes.
  2. Install location: accept the default (~/miniforge3) by pressing Enter.
  3. Initialize Miniforge3? Type yes. (This edits your ~/.bashrc to add the conda/mamba shell functions.)

After it finishes:

# Re-source so the conda init block takes effect:
source ~/.bashrc

# Verify:
which mamba
mamba --version
which python                   # should now point at ~/miniforge3/bin/python

✅ Self-check: mamba --version prints something like mamba 1.x.x.

2. Set strict channel priority (5 min)

conda config --set channel_priority strict

This avoids subtle dependency-resolution problems caused by packages with the same name living on multiple channels. See Handbook §3.4.

You can also clean up the channel list to use only conda-forge:

conda config --remove channels defaults 2>/dev/null || true
conda config --add channels conda-forge
cat ~/.condarc

3. Create your eslab project environment (10 min)

mamba create -n eslab python=3.11 numpy pandas matplotlib scikit-learn jupyter ipykernel psutil

This will: - Resolve a compatible set of versions (mamba does this in seconds; conda would take minutes) - Download a few hundred MB of packages - Install everything under ~/miniforge3/envs/eslab/

When it asks for confirmation, type y.

Activate the env:

mamba activate eslab

Your shell prompt should now show (eslab) at the start.

✅ Self-check: which python now points inside ~/miniforge3/envs/eslab/bin/python.

4. Sanity-check the environment (5 min)

python -c "import numpy; print('NumPy', numpy.__version__)"
python -c "import pandas; print('pandas', pandas.__version__)"
python -c "import sklearn; print('sklearn', sklearn.__version__)"
python -c "import psutil; print('psutil', psutil.__version__)"

All four lines should print a version. If any fail with ModuleNotFoundError, you forgot to activate the env or the install didn’t finish.

5. Inspect what’s installed (5 min)

mamba list

Note the Channel column on the right. Everything should say conda-forge (because of the strict channel priority you set in Task 2).

Try filtering:

mamba list | grep -i numpy
mamba list | head -20

6. Export environment.yml — two ways (10 min)

The naive export (everything, every version):

mamba env export -n eslab > environment_full.yml
wc -l environment_full.yml         # likely 100+ lines
head -30 environment_full.yml

The --from-history export (only what you explicitly asked for):

mamba env export -n eslab --from-history > environment.yml
cat environment.yml                # should be just ~10 lines

Compare the two. The --from-history form is the one you commit to a public GitHub repo for humans — it’s loosely pinned and recreates a working env even months later. The full export is more like a snapshot.

✅ Self-check: environment.yml lists python, numpy, pandas, etc. but not transitive deps like cycler or kiwisolver.

7. Register eslab as a Jupyter kernel (5 min)

So that when you launch Jupyter (Lab 7) you can pick “Python (eslab)” from the kernel menu:

python -m ipykernel install --user --name eslab --display-name "Python (eslab)"
jupyter kernelspec list

eslab should appear in the kernel list.

8. (Optional) Auto-activate on login (3 min)

If you’ll spend 90% of your shell time in eslab, add to the end of ~/.bashrc:

mamba activate eslab

Now every new SSH session lands in the env automatically. Skip this if you’d rather activate explicitly.

Deliverables

Save to lab05/ in your personal repo:

  1. lab05/environment.yml — the --from-history export from Task 6.

  2. lab05/mamba_list.txt — output of mamba list -n eslab (full list, with channel column visible).

  3. lab05/kernels.txt — output of jupyter kernelspec list.

  4. lab05/reflection.md — 4–6 sentences:

    • What’s the difference between environment.yml (--from-history) and environment_full.yml?
    • When would you commit the loose one to GitHub, and when the locked one?
    • What did conda config --set channel_priority strict change, and why?

Self-check

Common issues

❌ mamba: command not found after re-sourcing

The init block didn’t make it into .bashrc. Re-run:

~/miniforge3/bin/mamba init bash
source ~/.bashrc

❌ “Solving environment: failed”

You asked for an impossible combination of versions. Read the error message — mamba usually tells you which constraints conflict. Common fix: loosen pins or remove a problematic package.

❌ Install fails with “disk quota exceeded”

Mamba caches a lot of packages in ~/miniforge3/pkgs/. Clear it:

mamba clean -a

For genuinely long-term storage of multiple envs, see Handbook §5 on creating envs under /fs/project/<group>/envs/ where the quota is much larger.

❌ import sklearn works in the shell but fails in a Slurm job

Slurm runs your script in a fresh non-interactive shell that doesn’t auto-activate the env. Add this to your batch scripts (you’ll see it in Lab 8):

source ~/miniforge3/etc/profile.d/conda.sh
mamba activate eslab

❌ Two environments with similar names — eslab vs eslab_copy — and I can’t tell which is which

mamba env list           # lists all environments and their full paths

Time estimate

  • Reading: ~30 min
  • Tasks: ~50 min (mostly waiting for the installer and for mamba to download packages)
  • Deliverables: ~10 min

Total: ~1.5 hours

Extensions (optional)

Generate a lock file with conda-lock

For fully byte-exact reproducibility (useful for paper submissions):

mamba install -n base conda-lock
conda-lock lock -f environment.yml --platform linux-64
ls conda-lock.yml

The resulting conda-lock.yml pins every package version, build hash, and source URL. See Handbook §8.

Create a shared lab environment

If your lab has a /fs/project/<group>/ directory and you want one shared env everyone can activate:

mamba create -p /fs/project/<group>/envs/sharedlab python=3.11 numpy pandas
echo "envs_dirs:
  - /fs/project/<group>/envs" >> ~/.condarc
mamba env list                         # should now list `sharedlab`
mamba activate sharedlab               # works without a full path

Then in your ~/.bashrc you can ensure umask 002 is set so any packages you install into the shared env stay group-readable. (Lab 3.)

Install AI-assistant-friendly Python tooling

For better Python development:

mamba install -n eslab ruff black ipython

ruff is a fast linter; whichever AI assistant you installed in Lab 2 will use VS Code’s Problems panel to see what ruff flags and can offer to fix the issues directly.

What’s next?

With a working env, you’re ready for the cautionary tale of Lab 06 — The pip-conda trap and how to recover.