Quick answer: A MultiHostDsn import error usually means the project is mixing Pydantic generations, using an import path from a different release, or resolving an incompatible pydantic-settings package. Identify the interpreter and installed versions first, then align the dependency set and update imports to the documented API.
The error cannot import name MultiHostDsn from pydantic.networks means the code expects a Pydantic symbol that is not available from the installed Pydantic package. This is usually a version mismatch between your application, Pydantic, and a dependency that imports Pydantic internals.
Pydantic changed many APIs across major versions, and projects that support one major version may not support the other. The fix is to identify the installed version, check where the failing import comes from, then align the dependency versions instead of guessing.
This error often appears after a package upgrade, a fresh install on a new machine, or a deployment that resolves dependencies differently from local development. Treat it as a dependency compatibility problem first. The traceback and installed versions usually tell you which package needs to move.
Use the official Pydantic documentation, Pydantic network types documentation, Pydantic PyPI page, and Pydantic GitHub repository as primary references.
Check The Installed Pydantic Version
Start in the same environment that raises the error. Print the installed Pydantic version and the file path Python imports.
import pydantic
print(pydantic.__version__)
print(pydantic.__file__)
If the version is not the one your project expects, update the project requirements or install the compatible release in the active environment.
Also check the file path. If it points to an unexpected virtual environment, notebook kernel, or global Python install, you may be changing the wrong environment. Fixing the active environment is more important than reinstalling packages somewhere else.
Test The Import Directly
Run a small import check to confirm whether the symbol is available in the current environment.
try:
from pydantic.networks import MultiHostDsn
except ImportError as error:
print("MultiHostDsn import failed")
print(error)
else:
print(MultiHostDsn)
This separates a direct Pydantic import problem from a larger application startup problem. If the small check fails, focus on package versions first.
If the direct import works, but the application still fails, another package may be importing from a different path or running under another interpreter. In that case, compare the environment used by the application entry point.
Find Which Package Imports It
The traceback usually shows whether your code imports MultiHostDsn or whether another package imports it while loading.
import traceback
try:
import your_application
except ImportError:
traceback.print_exc(limit=8)
Replace your_application with the module that fails in your project. The last few traceback frames usually identify the package that needs a compatible version.
Read the traceback from bottom to top. The final line shows the ImportError, while the lines just above it often show the package that attempted the import. That package is usually the one whose version constraints need review.
Inspect Installed Package Versions
Use pip from the active interpreter to inspect Pydantic and related packages.
import subprocess
import sys
subprocess.run([
sys.executable,
"-m",
"pip",
"show",
"pydantic",
], check=False)
If a framework or library depends on Pydantic, check its documentation for supported Pydantic versions. Upgrade or pin dependencies as a set, not one package at a time.
For repeatable projects, record the working dependency set in a lock file or requirements file. Without that, a new install can choose newer packages and expose an ImportError that did not exist in the original environment.
Install A Compatible Version
If your project requires a specific Pydantic major version, install that version explicitly in the current environment.
import subprocess
import sys
subprocess.check_call([
sys.executable,
"-m",
"pip",
"install",
"pydantic>=2,<3",
])
This example pins the major version to Pydantic 2. If your dependency requires Pydantic 1, use the range documented by that dependency instead.
Avoid mixing incompatible ranges just to silence one error. If one dependency requires Pydantic 1 and another requires Pydantic 2, update one of the dependencies or separate the projects so each environment has a consistent set.
Verify The Environment After Changes
After changing packages, restart the Python process, notebook kernel, or application server. Then verify the version and import again.
import pydantic
print("Pydantic", pydantic.__version__)
try:
from pydantic.networks import MultiHostDsn
except ImportError as error:
print("Still failing:", error)
else:
print("Import works")
A restart matters because long-running processes keep old imports in memory. Without a restart, you may test the previous package state.
For notebooks, restart the kernel. For web apps, restart the application process. For workers, restart the worker process. The command that changed packages and the process that imports packages must agree.
Practical Checklist
Do not patch files inside site-packages to force this import. That creates a local change that disappears on the next install and can hide the real compatibility issue. Fix the package version relationship instead.
For applications, keep dependencies in a lock file or requirements file so every environment installs the same Pydantic major version. If a dependency upgrades to support a newer Pydantic release, update and test the dependency set together.
If the problem happens only in production, compare the resolved package list against local development. Differences in Python version, package index, or dependency resolver output can all lead to a different Pydantic release being installed.
The reliable pattern is to check the active environment, confirm the direct import, identify the package that imports MultiHostDsn, then align Pydantic and dependency versions. That fixes the immediate ImportError and makes future deployments repeatable.
Identify The Version Set
Print Python, pydantic, pydantic-settings, and the dependent framework versions from the same interpreter that runs the failing code. A lockfile and an interactive notebook can easily point at different environments.
Check The Import Path
Pydantic v1 and v2 reorganized some settings and network types. Search the installed package and official API docs for the version you actually support instead of copying an import from an older tutorial.
Align Settings Packages
Settings helpers are coupled to Pydantic’s major version. Pin compatible versions together and let the resolver expose conflicts rather than forcing one package to install over another.
Clear Shadowing And Stale State
A local module, multiple site-packages locations, or a long-running process can make a correct installation appear broken. Inspect module __file__ values and restart the process after changes.
Prefer Public Types
Use the public network and settings types supported by the selected release. Do not add a fake alias or monkey patch because the next validation or serialization step may fail differently.
Test Import And Validation
Test imports, URL parsing, multiple hosts, credentials handling, serialization, invalid input, a clean installation, and the exact application startup command.
Use the official Pydantic network types documentation and the installed release’s migration guide. Related Python Pool references include testing and diagnostics.
For related dependency debugging, compare import tests, version diagnostics, and settings mappings before changing Pydantic.
Frequently Asked Questions
What causes the MultiHostDsn import error?
The usual causes are a Pydantic v1 or v2 API mismatch, an incorrect import path, incompatible pydantic-settings versions, or a stale interpreter environment.
Where is MultiHostDsn imported from?
Use the import path documented for the Pydantic version and package set used by the project; do not assume a v1 import remains valid in v2.
Should I install another Pydantic version?
First identify the supported dependency range of the application and its settings package, then pin a compatible set instead of changing one package blindly.
Why does reinstalling not fix the import?
The running interpreter may differ from the installer, a notebook may retain old modules, or multiple site-packages directories may shadow the intended package.