Fix: Pipenv Not Working — Lock File Generation, Shell Activation, and Dependency Resolution

The Error

You install pipenv and try to lock — it hangs for hours:

$ pipenv lock
Locking [packages] dependencies...
# Spins for 30+ minutes, sometimes never completes

Or pipenv shell doesn’t activate:

$ pipenv shell
Spawning environment shell (/bin/bash)
# Shell opens but prompt doesn't show the venv name
# Or: command not found errors

Or the virtualenv lives in the wrong place:

$ pipenv install requests
# Creates venv in ~/.local/share/virtualenvs/myproject-XYZ123/
# But you wanted it in ./.venv/

Or dependency resolution conflicts:

Could not find a version that matches numpy<2.0,>=1.24
There are incompatible versions in the resolved dependencies

Or the Pipfile and Pipfile.lock get out of sync:

# Pipfile says: requests = "*"
# Pipfile.lock has: requests = "2.31.0"
# Someone manually edited the Pipfile but forgot to re-lock

Pipenv was the recommended Python dependency manager around 2018-2020 — combined Pipfile (human-readable) and Pipfile.lock (deterministic). It’s been overtaken by Poetry, uv, and PDM for new projects, but remains in widespread use. The biggest pain points are slow dependency resolution and venv location confusion. This guide covers each common issue and points to modern alternatives where appropriate.

Why This Happens

Pipenv uses pip’s resolver to find compatible versions. For large environments with many transitive dependencies, this resolution can take hours — sometimes never completes. The resolver explores the version space exhaustively without good heuristics.

Pipenv stores virtualenvs in a global cache directory (~/.local/share/virtualenvs/) by default, with a hashed name based on the project path. Moving the project directory invalidates the venv mapping; users get confused why a “fresh” venv is created in a new location.

Fix 1: Installing Pipenv

# Recommended — pipx isolates pipenv from project dependencies
pipx install pipenv

# Or pip with --user
pip install --user pipenv

# macOS
brew install pipenv

Common Mistake: Installing pipenv with pip install pipenv (no --user) into the system Python. This pollutes the global environment and can break system tools. Always use pipx, pip install --user, or brew install.

Verify install:

pipenv --version
pipenv --where   # Project location (run from project dir)
pipenv --venv    # Virtualenv path

Fix 2: Initialize a Project

mkdir myproject && cd myproject

# Initialize with specific Python version
pipenv --python 3.12

# Install a package — creates Pipfile and Pipfile.lock
pipenv install requests
pipenv install pydantic pandas

# Install dev-only dependency
pipenv install --dev pytest ruff

Resulting Pipfile:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
requests = "*"
pydantic = "*"
pandas = "*"

[dev-packages]
pytest = "*"
ruff = "*"

[requires]
python_version = "3.12"

Pin specific versions:

pipenv install requests==2.31.0
pipenv install "pydantic>=2.0,<3.0"

Install from a git repository:

pipenv install -e git+https://github.com/user/repo.git@main#egg=mypackage

Install from a local path:

pipenv install -e ./local-package

Fix 3: Lock File Generation — When It Hangs

$ pipenv lock
Locking [packages] dependencies...
# Hours pass, no progress

Causes:

1. Loose version constraints — package = "*" lets pip explore every version
2. Conflicting transitive deps — pip backtracks through many combinations
3. Many packages — resolution complexity grows non-linearly

Reduce resolution time:

# Pre-clear the resolver cache
pipenv lock --clear

# Limit Python compatibility (smaller search space)
# In Pipfile:
[requires]
python_version = "3.12"   # Was "3"

# Pin major dependencies tighter
pipenv install "requests>=2.31,<3.0"

Switch to pip-tools if pipenv lock is unworkable — uses the same Pipfile concepts but pip-compile is faster:

pip install pip-tools

# requirements.in
requests
pydantic
pandas

# Generate lock
pip-compile requirements.in -o requirements.txt

Pro Tip: For new projects in 2025, use uv instead of pipenv. uv’s resolver is 100x faster on the same workloads — what takes pipenv 5 minutes (or never completes), uv finishes in seconds. For uv migration, see uv not working. Pipenv is in maintenance mode; new development should move off it.

Skip the lock entirely for development:

pipenv install --skip-lock requests
# Faster install, but no lock file update — only for ephemeral envs

Fix 4: Virtualenv Location

Pipenv creates the venv in a global cache by default:

$ pipenv --venv
/Users/you/.local/share/virtualenvs/myproject-aBcDeF/

This path is hashed from the project directory — moving the project invalidates the venv mapping.

Force the venv inside the project directory:

# Set env var globally (recommended)
export PIPENV_VENV_IN_PROJECT=1

# Now `pipenv install` creates ./.venv/
cd myproject
pipenv install
ls .venv/   # Local venv

Add to your shell rc file:

# ~/.bashrc or ~/.zshrc
export PIPENV_VENV_IN_PROJECT=1

Common Mistake: Moving a project directory (or renaming it) and finding pipenv creates a brand new venv. The hash of the new path doesn’t match the cached one. Set PIPENV_VENV_IN_PROJECT=1 to make venvs travel with the project.

Delete the global venv if you no longer need it:

pipenv --rm
# Removes the venv associated with the current directory

Fix 5: Shell Activation

# Activate the venv in a subshell
pipenv shell

# Or run a command in the venv without activating
pipenv run python my_script.py
pipenv run pytest
pipenv run pip list

pipenv shell not working:

The most common cause is the shell environment not being correctly initialized. Check:

# What shell is pipenv using?
echo $SHELL

# Force a specific shell
SHELL=/bin/zsh pipenv shell

# Or use `pipenv run` which doesn't need shell activation
pipenv run python --version

For one-off commands, pipenv run is usually cleaner than pipenv shell:

pipenv run python -c "import requests; print(requests.__version__)"

Pro Tip: Prefer pipenv run for scripts and CI; use pipenv shell only for interactive development. run is more predictable — it doesn’t depend on shell hooks or env files. CI scripts that use pipenv shell often fail because the subshell doesn’t inherit CI variables correctly.

Fix 6: Pipfile vs Pipfile.lock

# Pipfile — human-edited, ranges
[packages]
requests = "*"            # Any version
pydantic = ">=2.0"        # 2.0 or higher
pandas = "~=2.2.0"        # Compatible release: >=2.2.0, <2.3.0

// Pipfile.lock — auto-generated, exact versions
{
    "_meta": {
        "hash": {"sha256": "..."}
    },
    "default": {
        "requests": {
            "version": "==2.31.0",
            "hashes": ["sha256:..."]
        }
    }
}

Workflow:

1. Edit Pipfile (or use pipenv install/uninstall)
2. pipenv lock regenerates Pipfile.lock
3. Commit both files

Install from lock (reproducible install):

pipenv install --deploy --ignore-pipfile
# --deploy: fail if Pipfile.lock is out of date
# --ignore-pipfile: use only Pipfile.lock, don't re-resolve

This is the production install command — fast, deterministic.

Common Mistake: Editing Pipfile manually but not running pipenv lock. The Pipfile and lock file drift, and developers running pipenv install get different versions than intended. Always run pipenv lock after Pipfile edits — or use pipenv install which updates both.

Generate requirements.txt for tools that need it:

pipenv requirements > requirements.txt
pipenv requirements --dev > requirements-dev.txt

Useful for Docker builds where you don’t want to install pipenv in the image, or for tools that only accept requirements.txt.

Fix 7: Dependency Resolution Conflicts

Could not find a version that matches numpy<2.0,>=1.24

The resolver couldn’t find a version satisfying all constraints. Common causes:

1. Transitive deps conflict — package A needs X >= 2, package B needs X < 2
2. Python version too narrow — your python_version = "3.13" excludes a package only built up to 3.12
3. Platform-specific packages — some wheels only exist for certain platforms

Diagnose:

pipenv graph
# Shows dependency tree with versions

pipenv graph --reverse
# Reverse: shows which packages depend on each

Manually relax constraints:

# Pipfile
[packages]
numpy = "*"      # Was "<2.0" — relax to let resolver succeed
pandas = "*"

Override a transitive dep:

[packages]
my-app = {file = ".", editable = true}
urllib3 = ">=2.0,<3.0"   # Force this version, overrides what other deps want

For PostgreSQL/asyncpg-related dependency conflicts that surface in pipenv, see asyncpg not working.

Fix 8: Migrating Off Pipenv

For active development moving away from pipenv, here are clean migration paths:

To Poetry:

pip install poetry
# Convert Pipfile to pyproject.toml manually, or use:
pip install dephell
dephell deps convert --from=pipfile --to=poetry

To uv:

# Generate requirements.txt from pipenv
pipenv requirements > requirements.txt
pipenv requirements --dev > requirements-dev.txt

# Initialize uv
uv init
uv add -r requirements.txt
uv add --dev -r requirements-dev.txt

To PDM:

pdm import   # Auto-detects Pipfile and converts

To plain pip + requirements.txt:

pipenv requirements > requirements.txt
pip install -r requirements.txt

For Poetry-specific patterns, see Poetry dependency conflict. For PDM patterns, see PDM not working. For uv-specific setup, see uv not working.

Common Mistake: Trying to migrate without converting Pipfile.lock. The lock file contains exact versions you want to preserve; without porting them, the new tool re-resolves and may pick different versions. Use pipenv requirements to get current versions, then pin them in the new tool’s config.

Still Not Working?

Pipenv in 2025 — Is It Still Maintained?

Pipenv is still maintained (low pace) but no longer the recommended tool for new projects. The Python Packaging Authority (PyPA) now points to several alternatives. For existing pipenv projects:

• Stable, working — fine to leave as-is
• Active development — consider migrating for the resolver speed gains
• New projects — use uv (recommended), Poetry, PDM, or Hatch

Docker Integration

FROM python:3.12-slim

RUN pip install pipenv

WORKDIR /app
COPY Pipfile Pipfile.lock ./
RUN pipenv install --deploy --system
# --system: install into the container's Python, not a venv

COPY . .
CMD ["python", "main.py"]

--system skips venv creation — Docker’s isolation makes the venv redundant. Faster builds, smaller images.

CI Integration

# .github/workflows/test.yml
- uses: actions/setup-python@v5
  with:
    python-version: "3.12"
- run: pip install pipenv
- run: pipenv install --deploy --dev
- run: pipenv run pytest

Cache the pipenv venv for faster CI:

- uses: actions/cache@v4
  with:
    path: ~/.local/share/virtualenvs
    key: pipenv-${{ runner.os }}-${{ hashFiles('Pipfile.lock') }}

For pre-commit hooks that work with pipenv projects, see pre-commit not working.

Combining with Tox / Nox

# tox.ini
[testenv]
allowlist_externals = pipenv
commands = pipenv run pytest

Or generate requirements and let tox handle the install:

pipenv requirements > requirements.txt
# Then have tox install from requirements.txt directly

For Tox patterns, see Tox not working. For Nox, see Nox not working.

Pipenv-Specific Workflow Tips

• Use pipenv check to scan for known security vulnerabilities in installed packages
• Use pipenv update to update all packages within their Pipfile constraints
• Use pipenv clean to uninstall packages not in Pipfile.lock (useful after manual edits)
• Use pipenv scripts (defined in Pipfile [scripts] section) for command shortcuts:

[scripts]
test = "pytest"
lint = "ruff check ."
serve = "uvicorn main:app --reload"

pipenv run test
pipenv run lint

Working with Multiple Python Versions

Pipenv respects pyenv if installed:

# Install Python 3.12 via pyenv
pyenv install 3.12.6

# Pipenv finds it automatically when you specify python_version
cd myproject
pipenv --python 3.12
# Uses pyenv-installed Python 3.12.6

If you have only one Python installed and Pipenv can’t find your desired version, it falls back to the system Python or fails — install the version first (via pyenv, uv, or system package manager).

Recovering From Broken State

If pipenv gets confused (corrupt cache, mismatched venv, weird errors):

# Nuclear option — delete venv and rebuild
pipenv --rm
pipenv install --dev

# Clear pip cache
pip cache purge

# If still broken, clear pipenv's own caches
rm -rf ~/.cache/pipenv/

Often faster than debugging the specific issue.

Pipfile Sources for Internal Indexes

For private package indexes (corporate PyPI mirrors, GitHub Packages):

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[[source]]
url = "https://internal.example.com/pypi/simple"
verify_ssl = true
name = "internal"

[packages]
public-package = "*"
private-package = {version = "*", index = "internal"}

The index = "internal" per-package directive picks which source to use. Without it, pipenv searches each index in order.

For pip-specific index configuration that interacts with pipenv, see pip could not build wheels.