Repository navigation
Description
Describe the issue as clearly as possible:
The mistral extra is declared without any version bound (mistral = ["mistralai"], pyproject.toml:48; the test dependency at pyproject.toml:75 likewise), so a fresh pip install "outlines[mistral]" resolves the latest SDK — currently mistralai 3.2.0 (released 2026-10-09). In the SDK versions that pip now resolves, Mistral, UserMessage, AssistantMessage and SystemMessage are no longer importable from the mistralai top level; the client lives at mistralai.client.Mistral and the message classes at mistralai.client.models.
Every code path in the adapter that touches the SDK still imports from the old top level, so every entry point — outlines.from_mistral, MistralTypeAdapter.format_input, and every Mistral/AsyncMistral generate/stream call — raises a raw ImportError before any request is sent. A fresh outlines[mistral] install is therefore completely unusable, and the project's own Mistral unit tests fail at collection time with the same error.
Steps/code to reproduce the bug:
python -m venv v
v/bin/pip install "outlines[mistral]" # resolves mistralai 3.2.0 as of 2026-10-11
v/bin/python - <<'EOF'
from outlines import from_mistral
from outlines.models.mistral import MistralTypeAdapter
from mistralai.client import Mistral # where the client lives in the resolved SDK
MistralTypeAdapter().format_input("hello") # ImportError: src/outlines/models/mistral.py:81
from_mistral(Mistral(api_key="x")) # ImportError: src/outlines/models/mistral.py:545
EOFConstructing a model directly and calling generate/stream hits the same imports (src/outlines/models/mistral.py:81, :101, :120) before any request is sent.
Observed at commit c52af8472c6fe8a607a733ec11b709476af77a96; the released 1.3.3 carries the same unversioned extra (its PyPI metadata has mistralai; extra == "mistral").
Expected result:
Per docs/features/models/mistral.md:5, installing outlines[mistral] should be all that is needed to use the Mistral API in Outlines, and the from_mistral docstring (src/outlines/models/mistral.py:526) says it creates "an Outlines Mistral model instance from a mistralai.Mistral client". Since pyproject.toml:48 declares the extra as plain mistralai with no upper bound, the extra advertises compatibility with whatever version pip resolves — today 3.2.0. A fresh install should therefore give working from_mistral / format_input / generate / stream entry points (or, alternatively, the extra should be bounded to the SDK versions the adapter actually supports).
Error message:
Observed on a fresh outlines[mistral] install (mistralai 3.2.0):
mistralai version in env: 3.2.0
outlines: 1.3.3
format_input(str): CRASH ImportError at mistral.py:81: cannot import name 'UserMessage' from 'mistralai' (unknown location)
from_mistral(sync): CRASH ImportError at mistral.py:545: cannot import name 'Mistral' from 'mistralai' (unknown location)
Mistral(model).generate: CRASH ImportError at mistral.py:81: cannot import name 'UserMessage' from 'mistralai' (unknown location)
Full tracebacks (same commit, editable install + pip install "outlines[mistral]" in a clean venv):
>>> MistralTypeAdapter().format_input("hello")
Traceback (most recent call last):
File "<string>", line 3, in <module>
File ".../lib/python3.12/functools.py", line 949, in _method
return method.__get__(obj, cls)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../src/outlines/models/mistral.py", line 81, in format_str_model_input
from mistralai import UserMessage
ImportError: cannot import name 'UserMessage' from 'mistralai' (unknown location)
>>> from_mistral(Mistral(api_key="x"))
Traceback (most recent call last):
File "<string>", line 4, in <module>
File ".../src/outlines/models/mistral.py", line 545, in from_mistral
from mistralai import Mistral as MistralClient
ImportError: cannot import name 'Mistral' from 'mistralai' (unknown location)
The project's own tests fail the same way at collection time:
$ python -m pytest tests/models/test_mistral.py tests/models/test_mistral_type_adapter.py -q
ERROR collecting tests/models/test_mistral.py
tests/models/test_mistral.py:8: in <module>
from mistralai import Mistral as MistralClient
E ImportError: cannot import name 'Mistral' from 'mistralai' (unknown location)
ERROR tests/models/test_mistral_type_adapter.py
tests/models/test_mistral_type_adapter.py:10: in <module>
from mistralai import (
E ImportError: cannot import name 'AssistantMessage' from 'mistralai' (unknown location)
Outlines/Python version information:
Version information
Details
$ python -c "from outlines import _version; print(_version.__version__)"
1.3.4.dev2+gc52af8472
$ python -c "import sys; print('Python', sys.version)"
Python 3.12.14 (main, Aug 25 2026, 13:50:33) [Clang 22.1.3 ]
$ pip freeze
annotated-types==0.8.0
anyio==4.15.1
attrs==26.1.0
cloudpickle==3.1.2
diskcache==5.6.3
eval_type_backport==0.4.0
genson==1.4.0
h11==0.16.0
httpcore2==2.13.1
httpx2==2.13.1
idna==3.20
Jinja2==3.1.6
jsonpath-python==1.1.6
jsonschema==4.26.0
jsonschema-specifications==2025.9.1
MarkupSafe==3.0.4
mistralai==3.2.0
opentelemetry-api==1.45.1
opentelemetry-semantic-conventions==0.66b1
-e git+https://github.com/dottxt-ai/outlines.git@c52af8472c6fe8a607a733ec11b709476af77a96#egg=outlines
outlines_core==0.2.14
pillow==12.3.0
pydantic==2.14.0
pydantic_core==2.50.0
python-dateutil==2.9.0.post0
referencing==0.37.0
rpds-py==2026.9.1
six==1.17.0
truststore==0.10.4
typing-inspection==0.4.4
typing_extensions==4.16.0
Commit tested: c52af8472c6fe8a607a733ec11b709476af77a96 — OS: macOS (arm64)
Context for the issue:
Root cause: src/outlines/models/mistral.py:81, :101, :120 and :545 import UserMessage/AssistantMessage/SystemMessage/Mistral from the mistralai top level, which the SDK versions pip currently resolves no longer exports (mistralai.client.Mistral, mistralai.client.models.UserMessage/AssistantMessage/SystemMessage still exist, and the 3.x client still exposes .chat.complete/.chat.stream at instance level). Combined with the unversioned extra in pyproject.toml:48 (and the unversioned test dep at pyproject.toml:75), every fresh outlines[mistral] install resolves an SDK whose import surface the adapter does not match.
I searched the open and closed issues/PRs for reports about this (mistralai, UserMessage) and found nothing related.
Happy to open a PR that updates the four imports to the mistralai.client surface — and/or bounds the extra in pyproject.toml to a known-compatible range — whichever you prefer.
Activity
BlueX888 commentedon Oct 11, 2026
Reproduced this. Root cause: src/outlines/models/mistral.py:81, :101, :120 and :545 import UserMessage/AssistantMessage/SystemMessage/Mistral from the mistralai top level, which mistralai>=2.0 no longer exports (the client moved to mistralai.client and the message classes to mistralai.client.models). Combined with the unversioned mistral extra at pyproject.toml:48, every fresh outlines[mistral] install resolves an SDK whose import surface the adapter no longer matches.
Minimal reproduction:
Observed output:
Fix is ready on
BlueX888:fix/prep-mistral-adapter-broken-against-mistralai-3(commitcdbd59fe). The adapter now imports the client from mistralai.client and the message classes from mistralai.client.models, keeping the old top-level imports as a fallback for mistralai 1.x; the mistral test files that imported the removed surface are updated, with a new SDK-compat regression test covering the new paths.Verified with:
python -m pytest tests/models/test_mistral.py tests/models/test_mistral_type_adapter.py tests/models/test_mistral_sdk_compat.py tests/models/test_provider_exceptions.py -m 'not api_call' -qHappy to open the PR once you confirm the approach or assign this to me.
Maherimtiyaz commentedon Oct 17, 2026
I'd like to work on this plan: add a dual-surface import shim so both mistralai 1.x and 3.x work.
BlueX888 commentedon Oct 17, 2026
@Maherimtiyaz thanks for picking this up — heads-up that an implementation is already open in #2073 (open since Oct 11): it imports the message classes per-surface so both mistralai 1.x and the 2.x/3.x client layout work, with tests pinned against both surfaces. If you're planning the same compatibility shape, #2073 may save you the work — happy to rebase it onto current main or hand it over if you'd rather take it in a different direction.