Run pip after conda, never the other way round, and do it inside a dedicated conda environment. The conda documentation says to install as many packages as possible with conda first, then use pip for the rest. If you need changes later, build a new environment rather than running conda again.
Why the order matters
Conda tracks the packages it installed. Pip changes made afterwards are outside that record. The Anaconda article on the topic explains that conda has limited ability to control packages it did not install, so running conda after pip can overwrite or break pip installed packages. Pip can also upgrade or remove a package that a conda package needs.
The same article calls pip stateful: the more the final state depends on the order of installs, the harder it is to reproduce.
The rules from the documentation
- Use pip only after conda has installed as many requirements as possible.
- Keep pip's default upgrade strategy of only if needed, so conda packages are not upgraded needlessly.
- Do not use pip's user install option in a conda environment.
- Use a separate conda environment so pip cannot affect others, and take care not to run pip in the base environment.
- When something must change, recreate the environment instead of running conda after pip.
- Keep conda and pip requirements in text files in version control.
What this means for security review
A mixed environment has two inventories. Conda knows about one layer and pip about the other. A review that reads only one of them misses part of the environment.
| Layer | Where to read it |
|---|---|
| Conda packages | The conda list output or an export |
| Pip packages | The pip section of an environment file, or the pip freeze output |
| Both together | A full list from the live environment, with the pip layer included |
The conda list reference has an option that omits pip only installed packages, so be sure you are not using it when you build a review list.
A check you can run
After building, run pip check to confirm the installed Python packages have compatible dependencies. The pip documentation shows it returns a non zero exit code when a requirement is missing or has the wrong version, which makes it easy to put in CI.
python -m pip check
Pip check verifies compatibility. It does not look for vulnerabilities, so it complements a scan and does not replace one.
Where to put hashes
Conda explicit specs can carry hashes for the conda layer. For the pip layer, hashed requirements do the same job. Together they cover both halves of the environment.
Safeguard's SBOM and dependency scanning is designed to read dependency manifests and lock files, so a clean split between a conda file and a pip requirements file gives it clear input. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that an inventory is only as complete as the sources fed into it.
Quick check
Can I run conda install after a few pip installs?
The documentation advises against it. Recreate the environment with the combined requirements instead.
Does pip check find vulnerable packages?
No. It only verifies that installed packages have compatible dependencies.
Sources
- Managing environments, conda documentation, fetched 19 October 2026.
- Using Pip in a Conda Environment, Anaconda, fetched 19 October 2026.
- pip check, pip documentation, fetched 19 October 2026.
- conda list, conda documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
