An AI assistant gets the pip install name wrong because Python has two names for one library: the distribution name you install and the import name you write in code. They often match, but not always. When they differ, the assistant may guess, and a wrong guess can install a different project entirely.
Two names, one library
The Python Packaging User Guide separates the terms. A distribution package is the thing you install. When you type pip install pkg, pkg is a distribution name. An import package is a Python module, so in import pkg the word pkg is an import name. The guide notes that most of the time a distribution provides one import package, and it gives numpy as an example of a project whose import package contains submodules such as numpy.linalg.
The scikit-learn install page shows the mismatch plainly. You install with pip install -U scikit-learn, then check it with python -c "import sklearn; sklearn.show_versions()". The install name is scikit-learn. The import name is sklearn.
An assistant that learned thousands of snippets with import sklearn can easily write an install line that mirrors the import. Sometimes that line fails. Sometimes it succeeds and pulls in something you never meant to run.
Why a wrong name is a security problem
A failed install is an annoyance. A successful install of the wrong project is a supply chain event. Anyone can publish a name on a public registry that is free, and a name that looks plausible for a popular import is a cheap thing to claim. If the assistant guesses an install name and you run it without checking, you have executed a stranger's package on your machine or in your build.
This is a close cousin of the problem described in typosquatting vs dependency confusion vs slopsquatting, but the cause is different. Nothing is hallucinated. The name is real, it is just the wrong project.
A four step check before you run the line
- Find the project's own install instructions. Open the library's official documentation, not the assistant's answer. Look for the exact install command.
- Compare the install name with the import name. If they differ, note both. Write the pair in the pull request description so a reviewer sees it.
- Open the registry page for the install name. Confirm the project description, the linked source repository, the release history and the maintainer match the library you intended.
- Install into an isolated environment first. Use a throwaway virtual environment, then check that the import you expected works and that
pip showreports the project you expected.
A quick reference for what to look at:
| Signal | What you want to see | Warning sign |
|---|---|---|
| Install name | Matches the official docs | Copied from the import line |
| Source link | Points to the project's real repository | Missing or unrelated |
| Release history | Steady, plausible versions | One brand new release |
| Description | Matches what the library does | Empty or generic |
The five minute vetting routine covers the same ground in more depth if you want a longer checklist. The packaging guide in distribution vs import package is also worth a read.
Make the right name the easy name
You can reduce guessing by giving the assistant the facts. Paste the install line from the official docs into the prompt, or keep a short file of approved install names for libraries your team uses often. When the assistant can read the correct name, it has no reason to infer one.
Lock the result. Once the right distribution is installed, record it with an exact version in your requirements file so the next person, or the next agent session, does not repeat the guess.
Try it yourself
Open the dependency inventory demo and look at how each component is listed by its package name and version. Notice that the inventory records what is installed, which is the name worth comparing with the assistant's line.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning lists what actually landed in your manifests and lockfiles, so a surprise package shows up in the inventory. You can also run a free scan at gold.safeguard.sh/scan.
Quick check
Is the pip install name always the same as the import name?
No. They match for many libraries but not all. scikit-learn is installed under that name and imported as sklearn. Always read the install command from the project's own documentation.
What if the install line works but the package looks odd?
Stop and inspect the registry page, source link and release history before using it. Remove it from the environment, and see whether your lockfile or requirements file recorded it.
Sources
- Python Packaging User Guide, Distribution package vs. import package: https://packaging.python.org/en/latest/discussions/distribution-package-vs-import-package/
- scikit-learn installation instructions: https://scikit-learn.org/stable/install.html
Last reviewed: 19 October 2026.
