On 28 April 2016 at 11:11, Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Apr 28, 2016 at 09:57:19AM +0100, Oscar Benjamin wrote: > >> You can write some code to test if a particular path represents the >> base directory of a virtual environment but I expect it would probably >> be fragile. Without knowing why you want to do this I suggest that you >> might want to find a different general approach to your real problem. > > You know, some day I must learn why people use virtual environments. Its > a total mystery to me. It makes a sort-of sense to me if you're talking > about old versions of Python before per-user site-packages were added, > but that's been available since version 2.6. So I don't get it.
They're useful for installing different versions of different packages without conflicting. Here's a typical example: I want to write a patch for sympy. First I need to check the latest git master to see if my patch is appropriate and then I need to write a patch against master. So I could install from master but maybe I already have some version of sympy installed that I don't want to mess with as I use it for other things. So I can create a virtual environment for this purpose: $ py3.5 -m virtualenv sympyvenv Using base prefix '/users/enojb/.python/python3.5.1' New python executable in /users/enojb/sympyvenv/bin/py3.5 Also creating executable in /users/enojb/sympyvenv/bin/python Installing setuptools, pip, wheel...done. Let's have a look at this: $ cd sympyvenv/ $ ls bin include lib pip-selfcheck.json Now we can activate it. This puts it on PATH so that e.g. "python" runs the python from this venv (likewise pip, ipython etc.). The PS1 prompt is changed to remind you that it is active: $ . bin/activate (sympyvenv) $ Now clone sympy here: (sympyvenv) $ git clone github.com:sympy/sympy.git # Or maybe your own fork Cloning into 'sympy'... remote: Counting objects: 179582, done. remote: Compressing objects: 100% (8/8), done. remote: Total 179582 (delta 0), reused 0 (delta 0), pack-reused 179574 Receiving objects: 100% (179582/179582), 75.12 MiB | 17.05 MiB/s, done. Resolving deltas: 100% (142458/142458), done. We can now install sympy in "editable" mode: (sympyvenv) $ pip install -e sympy/ Obtaining file:///users/enojb/sympyvenv/sympy Collecting mpmath>=0.19 (from sympy==1.0.1.dev0) Installing collected packages: mpmath, sympy Running setup.py develop for sympy Successfully installed mpmath-0.19 sympy At this point I've installed the VCS checkout of sympy within the virtual environment. I can go edit the code for sympy at will and test it out. It doesn't matter if I break sympy in this virtual environment as I only use it for working on sympy. You can create a different virtual environment for everything that you're working on and there's no need for them to share versions of any packages. Another case would be to build up some code that does something and then pin the versions of all the libraries it uses so that if you come back and run it in 3 years time then it won't have been broken by any updates to these libraries. -- Oscar _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
