Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 5 minute intro to virtualenv
Ähnlich wie 5 minute intro to virtualenv (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
5 minute intro to virtualenv
- 1. 5 minute introduction to 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
- 6. we need to switch between different sets of packages depending on what we are working on.
- 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..)
- 13. a python 'instance' (virtual environment) for each project
- 14. isolated site packages and scripts
- 15. alternatively inherit from system site packages
- 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 )
- 21. Works with pip and easy_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 virtualenv http://python.mirocommunity.org/video/4157/pycon-2011-reverse-engineering
- 25. Section Title pythons for everyone
- 26. DEMO
- 28. Don't use your operating systems packages as these projects change rapidly
- 30. Use pip and requirements files to make virtualenv builds repeatable Useful tips export PIP_RESPECT_VIRTUALENV=true
- 33. All virtual envs in one place ($WORKON_HOME)
- 34. Makes creating, deleting , switching etc.. between virtual envs really easy workon <env> switch to a ve deactivate unactivate current ve add2virtualenv add a path to the current ve mkvirtualenv rmvirtualenv cdsitepackages cd to ve's site-packages cdvirtualenv cd to the ve's dir cpvirtualenv
- 35. DEMO
- 39. convenient user interface via virtualenv-wrapper
- 40. requirements files and pip to populate your virtual envs
Hinweis der Redaktion
- I think this excerpt sums up the issues pretty well...
- So here are the main issues for the average developer Im working on many different things at the same time on my dev box Im wanting to also deploy many different apps to the server Both these scenarios require multiple python packages and versions to be available ! .. How can i acheive this?
- These are generalisations but generally true for 'default' methods of install. Main point being that default behaviour is one installed version per package and there is generally one place where all your packages go Don't read these out: sys.path - A python script can dynamically alter the search path pth files specify alternative locations to search for packages Environment variables can be used to tell python where to search for packages
- I use it while developing and also on the server for wsgi apps (although it requires some workarounds for that...) It satisfies the list of requirements earlier .. hopefully i can convince you in a moment
- No need to roll your own by hacking python path! This is horrible becuase its hard to debug environment variables and work out who or what set it
- Theres actually much more inside a virtualenv but this would be a bare minimum if you were to build one manually The custom site.py is what allows virtualenv to work – it ensures the virtual environments site-packages are used not the systems! From inside a virtualenvironment we can install directly to its site-packages
- The cat reminds me to do a demo cddemo virtualenv --no-site-packages testing #lets use 'active' to set our $PATH source testing/bin/activate which python python mpoimport os os.__file__ import sys sys.prefix # show local packages pip freeze -l pip install nose pip freeze -l
- PIP RESPECT VIRTUAL ENV : make sure pip installs to virtual env Theres a config file as well if you prefer Lots to configure read the manual VIRTUAL ENV USE DISTRIBUTE: use distribute instead of setuptools (hasn't made any difference for me )
- Nice interface for working with virtualenv , a bunch of shell scripts (bash and zsh...maybe others) I
- Cat reminds me to do a demo # lots of virtualenvs cd $WORKON_HOME ls -l workon sandbox pip freeze -l deactivate workon sandbox2 deactivate mkvirtualenv sandbox3 just let it run !
- Any questions ?