{"slug": "surprisingly-necessary-explanation-of-python-venv", "title": "Surprisingly necessary explanation of Python venv", "summary": "A developer explains the fundamentals of Python virtual environments, addressing common misconceptions and demonstrating how venvs solve dependency conflicts, enable offline package installation, and allow transferring entire environments between machines.", "body_md": "There is a strange phenomenon in the Python world. People train neural networks, automate infrastructure, write complex tools and maintain applications for years while still having very little understanding of Python virtual environments.\n\nI'm not entirely sure why this happens. Maybe it's because Python has such a low barrier to entry that beginners skip this topic just to get their first script running and then never come back to it as they progress further, focusing on Python syntax and programming skills instead.\n\nAt later stages of learning, this leads people to ask questions like:\n\nAll of these problems can be solved using basic virtual environment features, but many developers never develop that intuition.\n\nA Python virtual environment is not:\n\nA venv is simply a directory where your project-specific interpreter's configuration and project-specific dependencies live. Such an approach gives Python developers many useful features.\n\nLet’s start with the obvious one. Different projects require different dependencies. Sometimes the same dependencies, but in different versions. Installing everything globally in the system quickly creates chaos because some projects may start working after the dependency update and the others stop working due to the same reason.\n\nVirtual environments solve this by giving each project its own package space:\n\n```\nproject_a/.venv\nproject_b/.venv\n```\n\nEach environment contains independent:\n\nThis shifts the problem from *\"works on my machine\"* to *\"works with this venv\"* which limits debugging only to the content of the used virtual environment.\n\nWhen you run:\n\n```\nsource .venv/bin/activate\n```\n\nthe script mainly modifies your shell’s PATH variable so that *.venv/bin* appears before system directories. As a result, commands like `python`\n\nnow resolve to executables inside the virtual environment.\n\nSuch activation is optional and when creating automations or running scripts remotely, it is actually a good idea to explicitly run the interpreter directly:\n\n```\n./.venv/bin/python script.py\n```\n\nor:\n\n```\n./.venv/bin/python -m pip install requests\n```\n\n**AI is powerful. Snippets are instant.**\n\nStop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from [piko::snippets GitHub repository](https://github.com/pikotutorial/piko_snippets).\n\nThis is where things start becoming genuinely interesting. You may have already encountered the following setup:\n\n**Machine A:**\n\n**Machine B:**\n\nMany people assume this means that their Python tooling cannot be used on Machine B because how would they ensure proper dependencies. The answer is that you can build your dependencies as *.whl* packages, transfer them via internal network and install them offline on the server side. Let's say you need `empy`\n\nfor your application to work. On machine A create the virtual environment:\n\n```\npython3 -m venv machine_a\n```\n\nAnd then install empty with `pip`\n\n:\n\n```\n./machine_a/bin/python -m pip install empy\n```\n\nAfter it's done, display the installed packages to make sure it's there:\n\n```\n./machine_a/bin/python -m pip freeze\nempy==4.2.1\n```\n\nNow, build a wheel package:\n\n```\n/machine_a/bin/python -m pip wheel empy==4.2.1 -w deps\n```\n\nThis creates a *deps* folder with a *empy-4.2.1-py3-none-any.whl* file inside. Transfer that folder to the machine B and then create there a new virtual environment:\n\n```\npython3 -m venv machine_b\n```\n\nYou can now install the dependency fully offline out of the transferred *.whl* file:\n\n```\n./machine_b/bin/python -m pip install deps/empy-4.2.1-py3-none-any.whl\n```\n\nLet's restrict the environment of the machine B from the previous paragraph even more and let's say that you can't even install dependencies with `pip`\n\nout of *.whl* packages. What can you do? You can transfer entire virtual environment folder from machine A to the machine B and run your script there.\n\nThe venv package will provide everything that your scripts need (of course, as long as both machines are sufficiently compatible - they share OS family, architecture etc.).\n\nVirtual environment folder captures your dependencies and their versions, so whenever you need to know what dependencies you actually use and in what versions, you can simply run:\n\n```\n./venv/bin/python -m pip freeze\n```\n\nIf you save the output to the file (usually called *requirements.txt*) you can always re-create your venv by invoking:\n\n```\n./venv/bin/python -m pip install -r requirements.txt\n```\n\nIt means that you can just copy your current venv folder, tweak versions of some dependencies, check if your app still works and if yes - start using these new versions. If no, you simply delete the new venv folder and use the old one.", "url": "https://wpnews.pro/news/surprisingly-necessary-explanation-of-python-venv", "canonical_source": "https://dev.to/pikotutorial/surprisingly-necessary-explanation-of-python-venv-3d47", "published_at": "2026-07-27 05:00:00+00:00", "updated_at": "2026-07-27 05:35:18.854129+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Python"], "alternates": {"html": "https://wpnews.pro/news/surprisingly-necessary-explanation-of-python-venv", "markdown": "https://wpnews.pro/news/surprisingly-necessary-explanation-of-python-venv.md", "text": "https://wpnews.pro/news/surprisingly-necessary-explanation-of-python-venv.txt", "jsonld": "https://wpnews.pro/news/surprisingly-necessary-explanation-of-python-venv.jsonld"}}