Fixing Broken Python Environment on Windows: Lessons Learned

🚀 What I Learned Fixing a Broken Python Environment (Windows Case Study). 💡 Sharing this in case it helps someone else avoid the same pain. Over the past few days, while working on a data automation project, I ran into serious issues with: ❌ Virtual environments are conflicting ❌ Packages refusing to install ❌ Jupyter kernels not showing ❌ “Works on my machine” syndrome At first, it was frustrating. Then I realised: this is real engineering work. Here are the key lessons I’m taking forward: 1️⃣ One Project = One Virtual Environment Never reuse environments. Every project gets its own: python -m venv .venv Isolation prevents 80% of dependency problems. 2️⃣ Always Verify Your Interpreter Before installing anything, check: python -c "import sys; print(sys.executable)" If it’s wrong, everything else will be wrong. 3️⃣ Windows Builds Need Special Handling Some libraries (like psutil) try to compile from source and fail without C++ tools. Solution: pip install --only-binary=:all: psutil==5.9.8 Use pre-built wheels whenever possible. 4️⃣ Jupyter Needs Explicit Registration Installing ipykernel is not enough. You must register it: python -m ipykernel install --user --name project Otherwise, notebooks won’t see your environment. 5️⃣ Terminal Context Matters PowerShell ≠ Python. If you’re not inside Python, Python commands won’t work. Use: python -c "..." or a notebook. 💡 The Bigger Lesson Environment management is not “basic stuff”. It’s a core engineering skill. Most production failures start with: ➡️ “It worked on my machine.” Now I always verify my interpreter, venv, and kernel before writing a single line of code. #Python #DataEngineering #LearningInPublic #WindowsDev #VirtualEnvironment #Jupyter #TechCareers #CareerSwitch #BuildInPublic #DevLife

To view or add a comment, sign in

Explore content categories