🐍 Fix Pyenv Messing Up Your Distrobox (Pop!_OS, Ubuntu, Fedora, etc.)

You’ve set up your dream development environment:

• Your host system (maybe Pop!_OS, Ubuntu, or something similar) uses pyenv to manage many Python versions.
• For clean, reproducible builds, you spin up a Fedora container with Distrobox.

It feels like the best of both worlds… until something breaks.

Inside your container you type:

~$ which python3 ~/.pyenv/shims/python3 😖😩 

Instead of Fedora’s Python, it points to your host’s ~/.pyenv/shims/python3.
Your container isn’t clean anymore — your host has leaked into it.

Don’t panic. This is a common issue, and the fix is simple once you know what’s happening.

⚡ The Hidden Culprit: A Pyenv Shell Function

At first, you may think the problem is just the $PATH.
But that’s only part of the story.

The real issue is a pyenv shell function.

When you run this on your host:

eval "$(pyenv init -)" 

…it doesn’t only change your path. It also creates a function that overrides python. This function gets copied into your Distrobox container and takes priority over any path fixes you try.

So, to solve this:
👉 You need to remove the shell function and clean the path inside the container.

🛠️ The Smart .bashrc Fix

The best solution is to make your .bashrc “smart.”
With one block of code, it can detect whether you are on the host (Pop!_OS/Ubuntu) or inside a container (Fedora or others).

Replace your current pyenv settings with this block:

# ================================================================== # Pyenv & Distrobox Isolation # ================================================================== # Works on host (Pop!_OS, Ubuntu, etc.) and keeps containers (Fedora, etc.) # completely clean. if [ -z "$CONTAINER_ID" ]; then # --- HOST SYSTEM --- # Normal pyenv setup export PYENV_ROOT="$HOME/.pyenv" export PATH="$PYENV_ROOT/bin:$PATH" eval "$(pyenv init -)" else # --- GUEST (Distrobox Container) --- # Aggressively decontaminate the inherited host environment. # 1. Disable the pyenv shell function pyenv() { : # Does nothing } # 2. Rebuild PATH without pyenv entries _CLEAN_PATH="" OLD_IFS="$IFS"; IFS=':'; for p in $PATH; do case "$p" in # Explicitly skip any path containing .pyenv */.pyenv*) ;; # Skip pyenv paths *) if [ -n "$p" ]; then _CLEAN_PATH="${_CLEAN_PATH:+$_CLEAN_PATH:}$p" fi ;; esac done # Prepend the container's native paths to guarantee priority. export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:${_CLEAN_PATH}" IFS="$OLD_IFS" unset _CLEAN_PATH OLD_IFS fi 

After saving, close and reopen your terminals.

• On your host (Pop!_OS/Ubuntu), pyenv works as usual.
• Inside your Fedora container, you’ll get a clean, native /usr/bin/python3 🤩😍.

✅ Why This Is the Right Fix

This isn’t a quick hack — it’s a clean, long-term solution.

Pros:

• One-time setup: Update .bashrc once, and forget about it.
• True isolation: Both $PATH and the shell function are handled.
• Future-proof: If you later install pyenv inside the container, it works correctly.
• Clear boundaries: Keeps host and container separate.

Cons:

• Works only for bash. If you use zsh or fish, you’ll need to adapt it.
• Depends on .bashrc being loaded properly.

🎯 Conclusion

With this fix, you get the best of both worlds:

• Host (Pop!_OS/Ubuntu/ etc.): full pyenv power.
• Container (Fedora or other Distrobox guests): clean, isolated Python environment.

Now you can code with confidence, without pyenv sneaking into places it doesn’t belong.