Lately I have started to use venv virtual environments for my development. (before I was just using docker images and conda environments)
However I notice that virtual environments are created for some code you have.
My question is isn't that wasteful?
I mean if we have 20 repos of code, and they all need opencv, having 20 virtual environments make it install opencv 20 times?
What is under the hood of the virtual environment practice?
CodePudding user response：
My question is isn't that wasteful?
If you have N projects on same machine and all these projects using different versions of most imported libraries, venv is a good choice to be able guarantee that all projects are properly working as expected. In other way (if you have only single version of Python) you have to test all N pojects for compatibilty with single version. What is more wastful: spent time to check all libraries for compatibility with current version, or just install multiple versions of libraries checked and recommended by library provider?
I mean if we have 20 repos of code, and they all need opencv, having 20 virtual environments make it install opencv 20 times?
Actually you don't need to create venv for every single repo (project). it is just a folder and may be created outside source code directory (for example I use pyenv with virtualenv plugin that makes able to switch between envs independently of repo). So if you have 10 repos using opencv x.x and 10 repos using opencv y.y you may use only two venvs x.x and y.y
What is under the hood of the virtual environment practice?
In modern times of automation any processes venv is a simple way to be sure that automated process are using specified versions of libraries and here is no conflicts between versions on single worker (server). venv per project allow you create / destroy python environment at any time without worrying is it updated semewehere outise and updated at all? You don't need to maintenance environment and keep it fresh after creating. Just create → use → remove. of course if couple of processes are using same versions of libraries and start / stop working at same time (so venv may be deleted at same time), it will be better to use single environment for these projects
CodePudding user response：
There's a classic trade-off involved here. YES, the liberal use of virtualenvs requires more disk space...but these days, disk space is super cheap. The common consensus, which if you're an old timer like me then you would have come to on your own by now, is that the benefits of having a separate virtualenv for each of your projects VASTLY outweighs the downside of using some extra disk space. Of course, you can get by with fewer or even no virtualenvs.
I used to try to have fewer than one virtualenv per project. But that sometimes led to problems when I went to package up and distribute a particular project. Only if you have one virtualenv per project can you be 100% sure that the runtime environment you are using for testing your code will be identical to the one you'll represent in a requirements.txt file when you distribute your app.
PS: I just bought a refurbished 4TB hard drive on Amazon to use for backups. It cost me $38 dollars, shipped to me in one day! And 1TB SSDs can now be had for about $75. It's amazing how cheap "disk" space is these days.