pip install: Check It Exists (Yes, Every Single Time)

The thirty-second habit that tells a typo apart from a trap

7 min read

Argued into existence in the Writing Room7 messages · 1 mind changed
pip install: Check It Exists (Yes, Every Single Time)

Okay so — your assistant just handed you a line. Something like 'pip install some-package-name', sitting there in the chat, and the terminal is already open in the next window because you asked it to help you install something twenty seconds ago.

Your cursor is on that line. Hitting enter feels like nothing. It is not nothing.

I am not going to tell you to read the source code of every package before you install it, because you can't yet, and neither can most people who've been doing this for years. What I'm going to give you is a thirty-second habit that catches the version of this that actually hurts, and teaches you to tell it apart from the version that's just annoying.

Two failures, and only one of them is your fault

There are two ways an install line goes wrong, and beginners lump them into one feeling — "uh oh, I broke something" — when they are not the same thing at all.

One is you typing a package name that doesn't exist. Nobody registered it. Pip looks, finds nothing, and tells you so. Loudly, immediately, and it fixes itself the second you type the real name.

The other is a name that does exist — because someone put it there on purpose, hoping an AI assistant would hand it to exactly the person you are right now. That one doesn't yell at you. It says thank you and quietly does something you didn't ask for.

You need to be able to tell these apart before you hit enter, not after. Here's what each one actually looks like, run for real, not described from memory.

The harmless one

Open a terminal, make a fresh virtual environment, and try to install a name I just made up — watch for 'distribution' in the output, pip's word for an installable build, not a red flag:

python3 -m venv test-env
source test-env/bin/activate
pip install thispackagedefinitelydoesnotexist12345xyz
ERROR: Could not find a version that satisfies the requirement thispackagedefinitelydoesnotexist12345xyz (from versions: none)
ERROR: No matching distribution found for thispackagedefinitelydoesnotexist12345xyz

That's the whole event. Nothing installed, nothing ran, nothing changed on your machine. Read that message literally: pip checked the index, found nothing matching, and told you in the first sentence. You typo'd a name, or your assistant made one up out of thin air — same fix either way, which is to go check the real name and try again.

This is the "I broke Python" feeling, and it is almost never true. Pip failing loudly like this is pip working correctly.

The one that doesn't complain at all

Here's the failure that should actually worry you, and instead of just describing it, build the smallest possible version of it on your own machine so you see the shape of it with your own eyes. Nothing here touches PyPI — this package never leaves your laptop, which is exactly why it's safe to run.

Make a folder, and inside it a setup file that names the package one thing, plus a folder of actual code named something completely different:

mkdir mysterytool-demo && cd mysterytool-demo
mkdir totally_different_module
echo "print('loaded')" > totally_different_module/__init__.py
# setup.py
from setuptools import setup

setup(
    name="mysterytool",
    version="0.0.1",
    packages=["totally_different_module"],
)

That mismatch — the name in setup.py versus the folder that actually holds the code — is the entire trick a squatted package plays. Now install it, from your own folder, not from PyPI:

pip install .
Successfully installed mysterytool-0.0.1

No error. No warning. Pip did its job: a distribution named mysterytool existed — you just built it — it built, and it installed. Now try to actually use the thing you thought you were installing:

import mysterytool
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'mysterytool'

The name in setup.py is metadata, decoupled from what you import — that's the shape to recognize next time, not just this once. That's the tell. The install step succeeded and told you nothing was wrong, because as far as pip is concerned, nothing was — a distribution matched the name, files got copied to your machine. What those files actually did while they were copying, pip never checked, and neither did you, because there was nothing on screen asking you to look. I built this one to just print a word and go home; a real squat runs a setup script that reads your environment variables for API keys and cloud tokens and sends them somewhere, then fails quietly so you don't go looking.

The lesson is the same either way: "it installed with no errors" is not the same claim as "it's safe." The only difference between what you just built and a real attack is which name someone bothered to register on PyPI and what the setup script does instead of printing 'loaded' — the install step looks identical either way.

A name that got exactly this treatment

This isn't hypothetical. In late 2023, a security researcher named Bar Lanyado at Lasso Security noticed that AI coding assistants kept recommending a package called 'huggingface-cli' — a name that sounds completely reasonable for the command-line tool that ships with Hugging Face's libraries, except that isn't the actual package name and never was.

He registered it on PyPI himself, empty, just to see what would happen. Within three months it had over 30,000 downloads. Within 48 hours of him publishing his research on it, thousands of those downloads came from corporate IP ranges — people, or their agents, pasting a name their assistant invented straight into a terminal at work.

That name has since been pulled from PyPI — the Python Package Index, the registry pip installs from. Check it yourself right now, no install required — this is the same check you'd run on any package before you trust it, and it costs you nothing:

curl -s https://pypi.org/pypi/huggingface-cli/json
{"message": "Not Found"}

Gone. If your assistant hands you that exact line today, it would fail exactly like the made-up name did earlier — harmless, loud, obvious. The reason it isn't harmless as a lesson is that it wasn't always gone, and the next hallucinated name your assistant reaches for might not be either.

The thirty-second check, every time

Before you run any install line an assistant gives you — not just the ones that feel sketchy, every single one — open the package's real page and look at three things.

Does it exist, under that exact name? Go to 'pypi.org/project/<name>' yourself. A fresh, honest failure like the one above costs you nothing; finding out after 'Successfully installed' costs a lot more.

Does it link to a real repository? On the package's PyPI page, look for a 'Source' or 'Repository' link under Project Links. One that goes to an actual GitHub org with actual history is a good sign. No link at all, or a link to an empty repo, or a link to a repo with one commit from last Tuesday — that's the package equivalent of a business card with no address on it. If you're comfortable at a prompt, here's the same check as one command, run against a package you already trust:

curl -s https://pypi.org/pypi/requests/json | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['info']['project_urls'])"
{'Documentation': 'https://requests.readthedocs.io', 'Source': 'https://github.com/psf/requests'}

Is the history real? Click the "Release history" tab. A library that's been solving a real problem for years has a real trail of versions — point releases, changelogs, gaps that match a maintainer's actual life. A package that exists purely to catch a name your assistant might hallucinate usually has one version, published recently, and nothing before it — same as the demo you just built.

None of these three take more than ten seconds each. All three together is the "thirty-second check" I keep calling it, and you do it every time, not just when something feels off — because the whole point of a squatted name is that it doesn't feel off. It was built to feel exactly like the real thing.

Why this matters

You are going to be handed install lines constantly from here on. That's not a warning, it's just what building things with an assistant looks like now — because most of what it suggests is real and boring and fine.

The habit isn't about distrust. It's about knowing which of the two failures you're looking at before you've already found out the hard way. "No matching distribution found" means you made a typo, or your assistant did, and it costs you nothing but a retype. A name that resolves, installs cleanly, and does something you didn't ask for costs you your API keys.

Thirty seconds on the package page tells you which one you're holding before you hit enter, not after.

Final thought

Next time an assistant hands you an install line, don't paste it into the terminal first. Paste the package name into your browser instead — 'pypi.org/project/' plus whatever it gave you, or 'npmjs.com/package/' if you're in JavaScript — and look for a source link and a release history before you look for anything else.

If the page doesn't exist, or exists with nothing behind it, you've just found out for free. That's the whole habit.

pip install: Check It Exists (Yes, Every Single Time) | Vibecodes