1. 5 minute introductionto virtualenv

2. Python packages - challenges I'm a Python developer, and I'm developing multiple projects at the same time, perhaps in multiple versions, that have different dependencies. I need to reuse packages created by other developers, so I need an easy way to depend on such packages. These packages are sometimes in a rather early state of development, or perhaps I'm even creating a new one. If I want to improve such a package I depend on, I need an easy way to start hacking on it A history of python packaging: http://faassen.n--tree.net/blog/view/weblog/2009/11/09/0 3. Python packages challenges

we work with multiple projects and project versions each which may have:

- different package versions requirements

4. - incompatible packages 5. - packages currently in development we need to mirror production environments during development 6. we need to switch between different sets of packages depending on what we are working on. 7. Python packages - reality

By default everything installed into a single site-packages directory

8. on my machine: /usr/lib/python2.7/site-packages/ 9. Using distutils / setuptools there is one version per package 10. But there are lots of ways to put packages elsewhere (sys.path, .pth files, PYTHONPATH etc..) 11. Asolution ? virtualenv

developed by Ian Bicking ( also wrote pip)

12. available from pypi 13. a python 'instance' (virtual environment) for each project 14. isolated site packages and scripts 15. alternatively inherit from system site packages 16. Why use virtualenv ?

Widely used

17. Does one thing well (easy to learn) 18. Good support for lots of platforms (*nix, OSX, Windows) 19. Support for different python implementations (pypy, jython ) 20. No PYTHONPATH hacking 21. Works with pip and easy_install 22. How does it work?

A virtual environment is an independent instance of python on the filesystem , based on an existing python install.

23. Some tricks are used to make this work without copying your entire install 24. For more detail: PyCon 2011: Reverse-engineering Ian Bicking's brain: inside pip and virtualenvhttp://python.mirocommunity.org/video/4157/pycon-2011-reverse-engineering 25. Section Title pythons for everyone 26. DEMO 27.

It might be useful to setthis if you're using pip

28. Don't use your operating systems packagesas these projects change rapidly 29. (install from pypi) 30. Use pip and requirements files to make virtualenv builds repeatable Useful tips export PIP_RESPECT_VIRTUALENV=true 31. virtualenv-wrapper

Shell scripts for virtualenv

32. Available on pypi 33. All virtual envs in one place ($WORKON_HOME) 34. Makes creating, deleting , switching etc.. between virtual envs really easy workon switch to a ve deactivateunactivate current veadd2virtualenv add a path to the current vemkvirtualenvrmvirtualenvcdsitepackagescd to ve's site-packages cdvirtualenvcd to the ve's dir cpvirtualenv 35. DEMO 36. customisation

A bunch of hooks to use:

postactivate: run after environment is selected postmkvirtualenv: run after an environment is created Lots more: premvirtualenvpremkvirtualenv predeactivate postrmvirtualenv postdeactivate initialize 37. customisation

Postactivate

#!/bin/bash # This hook is run after every virtualenv is activated . export VIRTUAL_ENV_NAME=`basename $VIRTUAL_ENV` # cd to checked out project src_dir="${HOME}/src/${VIRTUAL_ENV_NAME}" if [[ -d "$src_dir" ]]; then cd "$src_dir" fi 38. Conclusion

isolated python instances via virtualenv

39. convenient user interface via virtualenv-wrapper 40. requirements files and pip to populate your virtual envs