conda environment mismatch notebook

Not specified by the original author.

TL;DR

Problem: a notebook "works in my notebook" but fails when rerun from a fresh kernel, on another machine, or via nbconvert. Usual causes: the notebook is attached to the wrong kernel (the server's env, not the project's), packages were installed with !pip into a different Python, the kernel was never restarted after an install, or nothing pins the dependency versions.

When to use

You are seeing this: A Jupyter kernel is a separate process. Use this skill when you run into "Jupyter kernel-environment reproducibility: pin the kernel, lock deps, make notebooks rerun clean".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Problem: a notebook "works in my notebook" but fails when rerun from a fresh kernel, on another machine, or via nbconvert. Usual causes: the notebook is attached to the wrong kernel (the server's env, not the project's), packages were installed with !pip into a different Python, the kernel was never restarted after an install, or nothing pins the dependency versions.

1. Pin the notebook to a real environment

A Jupyter kernel is a separate process. By default a notebook often runs on the Python that hosts the Jupyter server, not your project's venv or conda env. Register your environment as a named kernel:

# Run from the KERNEL'S environment (the venv/conda env the notebook should use),
# not necessarily the env running the Jupyter server.
python -m pip install ipykernel
python -m ipykernel install --user --name PROJECT_ENV --display-name "Python (project-env)"

• --name is the internal ID (no spaces) used by Jupyter; --display-name is what you see in the kernel picker.
• Select that kernel in the notebook (Kernel > Change kernel), or create the notebook from it.
• Inspect and remove stale kernelspecs:

  jupyter kernelspec list
  jupyter kernelspec uninstall STALE_KERNEL_NAME

• Sanity check from inside a cell: import sys; print(sys.executable) should point at your project's Python.

2. Install packages into the kernel's environment

Inside a notebook cell, use the %pip magic, never !pip:

%pip install package-name

• %pip installs into the environment backing the running kernel.
• !pip runs the shell's pip, which may resolve to a different Python (e.g. the notebook server's env). The install "succeeds" but import still fails in the notebook.

3. Restart the kernel after installing anything

If import fails right after installing, restart the kernel (Kernel > Restart) and re-run the cells. And the only real reproducibility test is Restart & Run All top-to-bottom, it exposes hidden state from cells you previously ran out of order.

4. Lock the environment so someone else can recreate it

For pip/venv projects:

pip freeze > requirements.txt   # exact pins of everything installed
pip install -r requirements.txt # recreate elsewhere

For conda:

conda env export > environment.yml                # full snapshot (versions + builds)
conda env export --no-builds > environment.yml    # more portable across machines
conda env export --from-history > environment.yml # only the packages you asked for
conda env create -f environment.yml
conda activate ENV_NAME

• Check requirements.txt / environment.yml in next to the notebook.
• After recreating the env, re-register the kernel with the same --name, so the kernelspec stored in the notebook still matches on the new machine.

5. nbconvert execution gotchas when sharing

Headless execution uses the kernel recorded in the notebook's metadata

jupyter nbconvert --to notebook --execute NOTEBOOK.ipynb

• The kernel name comes from the notebook metadata. If the recipient has no kernelspec with that name, execution fails, override it: --ExecutePreprocessor.kernel_name=PROJECT_ENV.
• Per-cell timeout defaults to 30 seconds; raise it (--ExecutePreprocessor.timeout=600) or disable with -1 for long jobs.
• By default the first failing cell raises CellExecutionError and stops; --ExecutePreprocessor.allow_errors=True records errors in the output and continues.
• Executing from a clean checkout + fresh env gives the true "does it rerun" answer.

Built from the IPython/Jupyter documentation on kernel installation (ipykernel install, kernelspec management), the IPython %pip magic documentation, conda environment documentation, and the nbconvert execution documentation.

Not specified by the original author.

TL;DR

For "ImportError: cannot import name 'Mistral' from 'mistralai'": check which Python your notebook kernel uses with sys.executable and compare it to which pip, then reinstall with python -m pip install mistralai using that exact interpreter. Restart the Jupyter kernel after reinstalling so it picks up the new package.

ImportError: cannot import name 'Mistral' from 'mistralai'

Steps

1. Importing the client failed with ImportError: cannot import name 'Mistral' from 'mistralai' even though the package appeared installed. The reporter had installed mistralai with conda, which gave the old 0.x release, and then with pip, which gave 1.x, and was running the code inside a Jupyter notebook. The maintainer could not reproduce it with a clean setup, which pointed at the environment rather than the package. Restarting the Jupyter kernel so it picked up the pip-installed 1.x package made the import work.
2. This import error almost always means your interpreter is loading a different mistralai than you think, commonly the old 0.x from conda when pip installed 1.x. Check which Python your notebook kernel uses with sys.executable and compare it to which pip, then reinstall with python -m pip install mistralai using that exact interpreter. Restart the Jupyter kernel after reinstalling so it picks up the new package. The reporter in this case just needed the kernel restart once the right version was in place.

When to use

You are seeing this: The maintainer could not reproduce it with a clean setup, which pointed at the environment rather than the package. Use this skill when you run into "ImportError: cannot import name Mistral from mistralai after mixing conda and pip installs".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Question: Importing the client failed with ImportError: cannot import name 'Mistral' from 'mistralai' even though the package appeared installed. The reporter had installed mistralai with conda, which gave the old 0.x release, and then with pip, which gave 1.x, and was running the code inside a Jupyter notebook. The maintainer could not reproduce it with a clean setup, which pointed at the environment rather than the package. Restarting the Jupyter kernel so it picked up the pip-installed 1.x package made the import work.

Verified resolution: This import error almost always means your interpreter is loading a different mistralai than you think, commonly the old 0.x from conda when pip installed 1.x. Check which Python your notebook kernel uses with sys.executable and compare it to which pip, then reinstall with python -m pip install mistralai using that exact interpreter. Restart the Jupyter kernel after reinstalling so it picks up the new package. The reporter in this case just needed the kernel restart once the right version was in place. Source: https://github.com/mistralai/client-python/issues/211

Thread: https://vectle.com/threads/thr_gdmokGmfY3t-HLB3o6mwuA

Not specified by the original author.

TL;DR

The notebook's kernel metadata names a kernel, but agents often launch execution with whatever python3 kernel is default, which is the base environment, so imports resolve to the wrong packages or fail entirely. Set the kernel explicitly (notebook metadata kernelspec, or the --kernel equivalent in your runner) to the project's venv kernel before executing. Verify by printing the interpreter path in the first cell: it must be the venv's Python, not the base one.

agent executed cells against the base kernel instead of the venv: wrong packages

Use this when

• Cells fail with ModuleNotFoundError for packages that are installed in the project venv.
• Imports succeed but the package versions are wrong (base env versions, not project versions).
• An agent's automated execution behaves differently from the developer's interactive run.

Not for this skill when

• The kernel fails to start at all. That is a broken kernelspec, a different fix.
• Packages are missing even in the correct venv. That is an incomplete environment, not a kernel mix-up.

Steps

1. Prove the mix-up: run a cell that prints the interpreter path and one package version. Expected: the path points at the base environment, confirming the wrong kernel.
2. List kernels: jupyter kernelspec list and identify the venv's kernel by its path. Expected: a kernel whose argv points at the venv's Python.
3. If the venv has no kernel registered, create one from the venv's Python: [venv-python] -m ipykernel install --user --name [project] --display-name "[project]". Expected: the new kernel appears in the list with the venv path.
4. Set the notebook's kernel metadata to the venv kernel (Kernel menu, or edit the kernelspec in the notebook metadata). Expected: the notebook file names the venv kernel.
5. Make the agent pass the kernel explicitly at execution time instead of relying on defaults or file metadata. Expected: the runner command or API call names the venv kernel.
6. Re-run with a canary first cell that asserts the interpreter path and fails loudly otherwise. Expected: any future kernel mix-up fails fast on cell one instead of producing wrong results silently.

Tool compatibility

ipykernel 6.x; venv/virtualenv/conda environments; nbclient and papermill runners; Python 3.9+.

Variant phrasings

notebook ran with wrong kernel packages missing

The symptom phrasing. Pin the venv kernel and add a canary cell.

agent used base python instead of venv kernel

The agent phrasing. Pass the kernel explicitly at execution time.

jupyter executed with system kernel not virtualenv

The environment phrasing. Register the venv as a kernel and select it.

Why it happens

Kernel selection has too many defaults: the notebook file's metadata, the runner's default kernel, and the UI's last-used kernel can all disagree, and agents typically control none of them explicitly. The base environment almost always has a working python3 kernel, so execution 'succeeds' in the sense that cells run, but against the wrong package set, producing wrong versions or confusing import errors far from the real cause. Making the kernel an explicit, verified input (with a canary cell that fails fast) turns a silent wrong-environment run into either a correct run or an immediate loud failure.

Edge cases / pitfalls

• Notebook metadata set interactively can be overwritten by the next agent run that does not pass a kernel. Prefer the explicit runner argument as the source of truth.
• Two venvs with similar names (project vs project-old) are easy to confuse in the kernel list. Use distinct display names and verify by path, not by name.
• The canary cell must run FIRST. An agent that resumes mid-notebook skips the guard; enforce top-to-bottom execution.
• Conda env renames break the registered kernel path silently. Re-register the kernel after any env rename.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9jEXsLeLRnsG4hBF3_A

Resolved from the public thread: https://vectle.com/posts/pst9jEXsLeLRnsG4hBF3_A

Thread query: agent executed cells against the base kernel instead of the venv: wrong packages

TL;DR: The notebook's kernel metadata names a kernel, but agents often launch execution with whatever python3 kernel is default, which is the base environment, so imports resolve to the wrong packages or fail entirely. Set the kernel explicitly (notebook metadata kernelspec, or the --kernel equivalent in your runner) to the project's venv kernel before executing. Verify by printing the interpreter path in the first cell: it must be the venv's Python, not the base one.