Commits

Doug Hellmann  committed 9be6d72 Merge

merge in spanish translation

  • Participants
  • Parent commits b81915a, 22870ac

Comments (0)

Files changed (36)

 .PHONY: html
 html:
 	(cd docs && $(MAKE) html SPHINXOPTS="-c sphinx/pkg")
+	(cd docs && $(MAKE) html SPHINXOPTS="-c sphinx/pkg" LANGUAGE="es")
 
 # Website copy of documentation
 .PHONY: website
 website: 
 	[ ~/Devel/doughellmann/doughellmann/templates/base.html -nt docs/sphinx/web/templates/base.html ] && (echo "Updating base.html" ; cp ~/Devel/doughellmann/doughellmann/templates/base.html docs/sphinx/web/templates/base.html) || exit 0
 	rm -rf docs/website
-	(cd docs && $(MAKE) html SPHINXOPTS="-c sphinx/web" BUILDDIR="website")
+	(cd docs && $(MAKE) html SPHINXOPTS="-c sphinx/web" BUILDDIR="website/en")
+	(cd docs && $(MAKE) html SPHINXOPTS="-c sphinx/web" BUILDDIR="website/es" LANGUAGE="es")
 
 installwebsite: website
-	(cd docs/website/html && rsync --rsh=ssh --archive --delete --verbose . www.doughellmann.com:/var/www/doughellmann/DocumentRoot/docs/virtualenvwrapper/)
+	(cd docs/website/en/html && rsync --rsh=ssh --archive --delete --verbose . www.doughellmann.com:/var/www/doughellmann/DocumentRoot/docs/virtualenvwrapper/)
+	(cd docs/website/es/html && rsync --rsh=ssh --archive --delete --verbose . www.doughellmann.com:/var/www/doughellmann/DocumentRoot/docs/virtualenvwrapper/es/)
 
 # Register the new version on pypi
 .PHONY: register
 	SUPPORTED_PYTHON_VERSIONS=$(PRIMARY_PYTHON_VERSION) $(MAKE) test-bash
 
 test-install:
-	bash ./tests/manual_test_install.sh `pwd`/dist "$(VERSION)"
+	bash ./tests/manual_test_install.sh `pwd`/dist "$(VERSION)"

File README.es.txt

+..   -*- mode: rst -*-
+
+#################
+virtualenvwrapper
+#################
+
+virtualenvwrapper es un conjunto de extensiones de la herramienta de Ian
+Bicking `virtualenv <http://pypi.python.org/pypi/virtualenv>`_. Las extensiones
+incluyen funciones para la creación y eliminación de entornos virtuales y por otro
+lado administración de tu rutina de desarrollo, haciendo fácil trabajar en más
+de un proyecto al mismo tiempo sin introducir conflictos entre sus dependencias.
+
+===============
+Características
+===============
+
+1. Organiza todos tus entornos virtuales en un sólo lugar.
+
+2. Funciones para administrar tus entornos virtuales (crear, eliminar, copiar).
+
+3. Usa un sólo comando para cambiar entre los entornos.
+
+4. Completa con Tab los comandos que toman un entorno virtual como argumento.
+
+5. Ganchos configurables para todas las operaciones.
+
+6. Sistema de plugins para la creación de extensiones compartibles.
+
+Rich Leland ha grabado un pequeño `screencast
+<http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/>`__
+mostrando las características de virtualenvwrapper.
+
+
+===========
+Instalación
+===========
+
+Ve a la `documentación del proyecto <http://www.doughellmann.com/docs/virtualenvwrapper/>`__
+para las instrucciones de instalación y configuración.
+
+Actualizar desde 1.x
+====================
+
+El script de shell que contiene las funciones ha sido renombrado en la serie
+2.x para reflejar el hecho de que otros shells, además de bash, son soportados. En
+tu archivo de inicio del shell, cambia ``source
+/usr/local/bin/virtualenvwrapper_bashrc`` por ``source
+/usr/local/bin/virtualenvwrapper.sh``.
+
+==============
+Contribuciones
+==============
+
+Antes de contribuir con nuevas características al *core* de virtualenvwrapper,
+por favor considera, en vez, si no debe ser implementada como una extensión.
+
+Ve a la `documentación para desarrolladores 
+<http://www.doughellmann.com/docs/virtualenvwrapper/developers.html>`__
+por trucos sobre parches.
+
+========
+Licencia
+========
+
+Copyright Doug Hellmann, All Rights Reserved
+
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose and without fee is hereby granted,
+provided that the above copyright notice appear in all copies and that
+both that copyright notice and this permission notice appear in
+supporting documentation, and that the name of Doug Hellmann not be used
+in advertising or publicity pertaining to distribution of the software
+without specific, written prior permission.
+
+DOUG HELLMANN DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+EVENT SHALL DOUG HELLMANN BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
+USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
+OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+PERFORMANCE OF THIS SOFTWARE.
+
+.. _BitBucket: http://bitbucket.org/dhellmann/virtualenvwrapper/overview/

File announce.es.rst

+¿Qué es virtualenvwrapper?
+==========================
+
+virtualenvwrapper es un conjunto de extensiones de la herramienta de Ian
+Bicking `virtualenv <http://pypi.python.org/pypi/virtualenv>`_. Las extensiones
+incluyen funciones para la creación y eliminación de entornos virtuales y por otro
+lado administración de tu rutina de desarrollo, haciendo fácil trabajar en más
+de un proyecto al mismo tiempo sin introducir conflictos entre sus dependencias.
+
+
+¿Qué es lo nuevo en 2.1?
+========================
+
+El principal propósito de esta *release* es un conjunto de mejoras para soportar
+virtualenvwrapper.project_, una nueva extensión para administrar los directorios
+de trabajo para los proyectos con plantillas. 2.1 también incluye pequeños
+cambios y corrección de bugs.
+
+- Agregado soporte para ksh. Gracias a Doug Latornell por hacer la investigación
+  sobre qué era necesario cambiar.
+- Testeo de importación de virtualenvwrapper.hook_loader en el inicio que reporta
+  el error de manera que debería ayudar al usuario a resolver cómo solucionarlo
+  (ticket #33).
+- Actualizada la documentación de mkvirtualenv para incluir el hecho de que un
+  nuevo entorno es activado inmediatamente luego de que es creado (ticket #30).
+- Agregados ganchos alrededor cpvirtualenv.
+- *deactivation* es más robusto, especialmente bajo ksh.
+- Uso del módulo de Python ``tempfile`` para creación de archivos temporales
+  de forma segura y portable.
+- Corregido un problema con ``virtualenvwrapper_show_workon_options`` que
+  causaba que este muestre ``*`` como el nombre de un virtualenv cuando no había
+  entornos creados todavía.
+- Cambio en el cargador de ganchos para que pueda ejecutar sólo un conjunto de
+  ganchos nombrados.
+- Agregado soporte para listar los ganchos disponibles, para ser usado en la
+  ayuda de los comandos como mkproject en virtualenvwrapper.project.
+- Corregida la opción -h de mkvirtualenv.
+- Cambiado el registro para que $WORKON_HOME/hook.log rote después de 10KiB.
+
+
+.. _virtualenv: http://pypi.python.org/pypi/virtualenv
+
+.. _virtualenvwrapper: http://www.doughellmann.com/projects/virtualenvwrapper/
+
+.. _virtualenvwrapper.project: http://www.doughellmann.com/projects/virtualenvwrapper.project/

File docs/Makefile

 # Makefile for Sphinx documentation
 #
 
+# If doc language is English you don't need to set this variable
+LANGUAGE      = en
+
 # You can set these variables from the command line.
 SPHINXOPTS    =
 SPHINXBUILD   = sphinx-build
 PAPER         =
-BUILDDIR      = build
+BUILDDIR      = build/$(LANGUAGE)
 
 # Internal variables.
 PAPEROPT_a4     = -D latex_paper_size=a4
 PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) $(LANGUAGE)
 
 .PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
 

File docs/en/command_ref.rst

+.. Quick reference documentation for virtualenvwrapper command line functions
+    Originally contributed Thursday, May 28, 2009 by Steve Steiner (ssteinerX@gmail.com)
+
+.. _command:
+
+#################
+Command Reference
+#################
+
+All of the commands below are to be used on the Terminal command line.
+
+=====================
+Managing Environments
+=====================
+
+.. _command-mkvirtualenv:
+
+mkvirtualenv
+------------
+
+Create a new environment, in the WORKON_HOME.
+
+Syntax::
+
+    mkvirtualenv [options] ENVNAME
+
+All command line options are passed directly to ``virtualenv``.  The
+new environment is automatically activated after being initialized.
+
+::
+
+    $ workon
+    $ mkvirtualenv mynewenv
+    New python executable in mynewenv/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (mynewenv)$ workon
+    mynewenv
+    (mynewenv)$ 
+
+.. seealso::
+
+   * :ref:`scripts-premkvirtualenv`
+   * :ref:`scripts-postmkvirtualenv`
+
+rmvirtualenv
+------------
+
+Remove an environment, in the WORKON_HOME.
+
+Syntax::
+
+    rmvirtualenv ENVNAME
+
+You must use :ref:`command-deactivate` before removing the current
+environment.
+
+::
+
+    (mynewenv)$ deactivate
+    $ rmvirtualenv mynewenv
+    $ workon
+    $
+
+.. seealso::
+
+   * :ref:`scripts-prermvirtualenv`
+   * :ref:`scripts-postrmvirtualenv`
+
+.. _command-cpvirtualenv:
+
+cpvirtualenv
+------------
+
+Duplicate an environment, in the WORKON_HOME.
+
+Syntax::
+
+    cpvirtualenv ENVNAME TARGETENVNAME
+
+.. note::
+
+   The environment created by the copy operation is made `relocatable
+   <http://virtualenv.openplans.org/#making-environments-relocatable>`__.
+
+::
+
+    $ workon 
+    $ mkvirtualenv source
+    New python executable in source/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (source)$ cpvirtualenv source dest
+    Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install relative
+    Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install-2.6 relative
+    Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/pip relative
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postdeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/preactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/predeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    (dest)$ workon 
+    dest
+    source
+    (dest)$ 
+
+.. seealso::
+
+   * :ref:`scripts-precpvirtualenv`
+   * :ref:`scripts-postcpvirtualenv`
+   * :ref:`scripts-premkvirtualenv`
+   * :ref:`scripts-postmkvirtualenv`
+
+==================================
+Controlling the Active Environment
+==================================
+
+workon
+------
+
+List or change working virtual environments
+
+Syntax::
+
+    workon [environment_name]
+
+If no ``environment_name`` is given the list of available environments
+is printed to stdout.
+
+::
+
+    $ workon 
+    $ mkvirtualenv env1
+      New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ mkvirtualenv env2
+    New python executable in env2/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env2)$ workon 
+    env1
+    env2
+    (env2)$ workon env1
+    (env1)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ workon env2
+    (env2)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env2
+    (env2)$ 
+
+
+.. seealso::
+
+   * :ref:`scripts-predeactivate`
+   * :ref:`scripts-postdeactivate`
+   * :ref:`scripts-preactivate`
+   * :ref:`scripts-postactivate`
+
+.. _command-deactivate:
+
+deactivate
+----------
+
+Switch from a virtual environment to the system-installed version of
+Python.
+
+Syntax::
+
+    deactivate
+
+.. note::
+
+    This command is actually part of virtualenv, but is wrapped to
+    provide before and after hooks, just as workon does for activate.
+
+::
+
+    $ workon 
+    $ echo $VIRTUAL_ENV
+
+    $ mkvirtualenv env1
+    New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ deactivate
+    $ echo $VIRTUAL_ENV
+
+    $ 
+
+.. seealso::
+
+   * :ref:`scripts-predeactivate`
+   * :ref:`scripts-postdeactivate`
+
+==================================
+Quickly Navigating to a virtualenv
+==================================
+
+There are two functions to provide shortcuts to navigate into the
+currently-active virtualenv.
+
+cdvirtualenv
+------------
+
+Change the current working directory to ``$VIRTUAL_ENV``.
+
+Syntax::
+
+    cdvirtualenv [subdir]
+
+Calling ``cdvirtualenv`` changes the current working directory to the
+top of the virtualenv (``$VIRTUAL_ENV``).  An optional argument is
+appended to the path, allowing navigation directly into a
+subdirectory.
+
+::
+
+    $ mkvirtualenv env1
+    New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ cdvirtualenv
+    (env1)$ pwd
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ cdvirtualenv bin
+    (env1)$ pwd
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1/bin
+
+cdsitepackages
+--------------
+
+Change the current working directory to the ``site-packages`` for
+``$VIRTUAL_ENV``.
+
+Syntax::
+
+    cdsitepackages [subdir]
+
+Because the exact path to the site-packages directory in the
+virtualenv depends on the version of Python, ``cdsitepackages`` is
+provided as a shortcut for ``cdvirtualenv
+lib/python${pyvers}/site-packages``. An optional argument is also
+allowed, to specify a directory hierarchy within the ``site-packages``
+directory to change into.
+
+::
+
+    $ mkvirtualenv env1
+    New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ cdsitepackages PyMOTW/bisect/
+    (env1)$ pwd
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1/lib/python2.6/site-packages/PyMOTW/bisect
+
+lssitepackages
+--------------
+
+Calling ``lssitepackages`` shows the content of the ``site-packages``
+directory of the currently-active virtualenv.
+
+Syntax::
+
+    lssitepackages
+
+::
+
+    $ mkvirtualenv env1
+    New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ $ workon env1
+    (env1)$ lssitepackages 
+    distribute-0.6.10-py2.6.egg     pip-0.6.3-py2.6.egg
+    easy-install.pth                setuptools.pth
+
+===============
+Path Management
+===============
+
+add2virtualenv
+--------------
+
+Adds the specified directories to the Python path for the
+currently-active virtualenv.
+
+Syntax::
+
+    add2virtualenv directory1 directory2 ...
+
+Sometimes it is desirable to share installed packages that are not in
+the system ``site-pacakges`` directory and which should not be
+installed in each virtualenv.  One possible solution is to symlink the
+source into the environment ``site-packages`` directory, but it is
+also easy to add extra directories to the PYTHONPATH by including them
+in a ``.pth`` file inside ``site-packages`` using ``add2virtualenv``.
+
+1. Check out the source for a big project, such as Django.
+2. Run: ``add2virtualenv path_to_source``.
+3. Run: ``add2virtualenv``.
+4. A usage message and list of current "extra" paths is printed.
+
+The directory names are added to a path file named
+``virtualenv_path_extensions.pth`` inside the site-packages directory
+for the environment.
+
+*Based on a contribution from James Bennett and Jannis Leidel.*

File docs/en/developers.rst

+##############
+For Developers
+##############
+
+If you would like to contribute to virtualenvwrapper directly, these
+instructions should help you get started.  Patches, bug reports, and
+feature requests are all welcome through the `BitBucket site
+<http://bitbucket.org/dhellmann/virtualenvwrapper/>`_.  Contributions
+in the form of patches or pull requests are easier to integrate and
+will receive priority attention.
+
+.. note::
+
+  Before contributing new features to virtualenvwrapper core, please
+  consider whether they should be implemented as an extension instead.
+
+Building Documentation
+======================
+
+The documentation for virtualenvwrapper is written in reStructuredText
+and converted to HTML using Sphinx. The build itself is driven by
+make.  You will need the following packages in order to build the
+docs:
+
+- Sphinx
+- docutils
+
+Once all of the tools are installed into a virtualenv using
+pip, run ``make html`` to generate the HTML version of the
+documentation::
+
+    $ make html
+    rm -rf virtualenvwrapper/docs
+    (cd docs && make html SPHINXOPTS="-c sphinx/pkg")
+    sphinx-build -b html -d build/doctrees  -c sphinx/pkg source build/html
+    Running Sphinx v0.6.4
+    loading pickled environment... done
+    building [html]: targets for 2 source files that are out of date
+    updating environment: 0 added, 2 changed, 0 removed
+    reading sources... [ 50%] command_ref
+    reading sources... [100%] developers
+    
+    looking for now-outdated files... none found
+    pickling environment... done
+    checking consistency... done
+    preparing documents... done
+    writing output... [ 33%] command_ref
+    writing output... [ 66%] developers
+    writing output... [100%] index
+    
+    writing additional files... search
+    copying static files... WARNING: static directory '/Users/dhellmann/Devel/virtualenvwrapper/plugins/docs/sphinx/pkg/static' does not exist
+    done
+    dumping search index... done
+    dumping object inventory... done
+    build succeeded, 1 warning.
+    
+    Build finished. The HTML pages are in build/html.
+    cp -r docs/build/html virtualenvwrapper/docs
+    
+The output version of the documentation ends up in
+``./virtualenvwrapper/docs`` inside your sandbox.
+
+Running Tests
+=============
+
+The test suite for virtualenvwrapper uses `shunit2
+<http://shunit2.googlecode.com/>`_.  To run the tests under bash, sh,
+and zsh, use ``make test``.  To add new tests, modify or create an
+appropriate script in the ``tests`` directory.

File docs/en/extensions.rst

+=====================
+ Existing Extensions
+=====================
+
+Below is a list of some of the extensions available for use with
+virtualenvwrapper.
+
+.. _extensions-user_scripts:
+
+project
+=======
+
+The project_ extension adds development directory management with
+templates to virtualenvwrapper.
+
+bitbucket
+---------
+
+The bitbucket_ project template creates a working directory and
+automatically clones the repository from BitBucket.  Requires
+project_.
+
+.. _project: http://www.doughellmann.com/projects/virtualenvwrapper.project/
+
+.. _bitbucket: http://www.doughellmann.com/projects/virtualenvwrapper.bitbucket/
+
+emacs-desktop
+=============
+
+Emacs desktop-mode_ lets you save the state of emacs (open buffers,
+kill rings, buffer positions, etc.) between sessions.  It can also be
+used as a project file similar to other IDEs.  The emacs-desktop_
+plugin adds a trigger to save the current desktop file and load a new
+one when activating a new virtualenv using ``workon``.
+
+.. _desktop-mode: http://www.emacswiki.org/emacs/DeskTop
+
+.. _emacs-desktop: http://www.doughellmann.com/projects/virtualenvwrapper-emacs-desktop/
+
+user_scripts
+============
+
+The ``user_scripts`` extension is delivered with virtualenvwrapper and
+enabled by default.  It implements the user customization script
+features described in :ref:`scripts`.

File docs/en/history.rst

+===============
+Release History
+===============
+
+2.1
+
+  - Add support for ksh.  Thanks to Doug Latornell for doing the
+    research on what needed to be changed.
+  - Test import of virtualenvwrapper.hook_loader on startup and report
+    the error in a way that should help the user figure out how to fix
+    it (issue #33).
+  - Update :ref:`command-mkvirtualenv` documentation to include the
+    fact that a new environment is activated immediately after it is
+    created (issue #30).
+  - Added hooks around :ref:`command-cpvirtualenv`.
+  - Made deactivation more robust, especially under ksh.
+  - Use Python's ``tempfile`` module for creating temporary filenames
+    safely and portably.
+  - Fix a problem with ``virtualenvwrapper_show_workon_options`` that
+    caused it to show ``*`` as the name of a virtualenv when no
+    environments had yet been created.
+  - Change the hook loader so it can be told to run only a set of
+    named hooks.
+  - Add support for listing the available hooks, to be used in help
+    output of commands like virtualenvwrapper.project's mkproject.
+  - Fix mkvirtualenv -h option behavior.
+  - Change logging so the $WORKON_HOME/hook.log file rotates after
+    10KiB.
+
+2.0.2
+
+  - Fixed issue #32, making virtualenvwrapper.user_scripts compatible
+    with Python 2.5 again.
+
+2.0.1
+
+  - Fixed issue #29, to use a default value for ``TMPDIR`` if it is
+    not set in the user's shell environment.
+
+2.0
+
+  - Rewrote hook management using Distribute_ entry points to make it
+    easier to share extensions.
+
+.. _Distribute: http://packages.python.org/distribute/
+
+1.27
+  
+  - Added cpvirtualenv command [Thomas Desvenain]
+
+1.26
+
+  - Fix a problem with error messages showing up during init for users
+    with the wrappers installed site-wide but who are not actually
+    using them.  See issue #26.
+  - Split up the tests into multiple files.
+  - Run all tests with all supported shells.
+
+1.25
+
+  - Merged in changes to cdsitepackages from William McVey.  It now
+    takes an argument and supports tab-completion for directories
+    within site-packages.
+
+1.24.2
+
+  - Add user provided :ref:`tips-and-tricks` section.
+  - Add link to Rich Leland's screencast to :ref:`references` section.
+
+1.24.1
+
+  - Add license text to the header of the script.
+
+1.24
+
+  - Resolve a bug with the preactivate hook not being run properly.
+    Refer to issue #21 for complete details.
+
+1.23
+
+  - Resolve a bug with the postmkvirtualenv hook not being run
+    properly.  Refer to issues #19 and #20 for complete details.
+
+1.22
+
+  - Automatically create any missing hook scripts as stubs with
+    comments to expose the feature in case users are not aware of it.
+
+1.21
+
+  - Better protection of ``$WORKON_HOME`` does not exist when the wrapper script is sourced.
+
+1.20
+
+  - Incorporate lssitepackages feature from Sander Smits.
+  - Refactor some of the functions that were using copy-and-paste code to build path names.
+  - Add a few tests.
+
+1.19
+
+  - Fix problem with add2virtualenv and relative paths. Thanks to Doug Latornell for the bug report James Bennett for the suggested fix.
+
+1.18.1
+
+  - Incorporate patch from Sascha Brossmann to fix a issue #15. Directory normalization was causing ``WORKON_HOME`` to appear to be a missing directory if there were control characters in the output of ``pwd``.
+
+1.18
+
+  - Remove warning during installation if sphinxcontrib.paverutils is not installed. (#10)
+  - Added some basic developer information to the documentation.
+  - Added documentation for deactivate command.
+
+1.17
+
+  - Added documentation updates provided by Steve Steiner.
+
+1.16
+
+  - Merged in changes to ``cdvirtualenv`` from wam and added tests and docs.
+  - Merged in changes to make error messages go to stderr, also provided by wam.
+
+1.15
+  - Better error handling in mkvirtualenv.
+  - Remove bogus VIRTUALENV_WRAPPER_BIN variable.
+
+1.14
+  - Wrap the virtualenv version of deactivate() with one that lets us invoke
+    the predeactivate hooks.
+  - Fix virtualenvwrapper_show_workon_options for colorized versions of ls and
+    write myself a note so I don't break it again later.
+  - Convert test.sh to use true tests with `shunit2 <http://shunit2.googlecode.com/>`_
+
+1.13
+  - Fix issue #5 by correctly handling symlinks and limiting the list of envs to things 
+    that look like they can be activated.
+
+1.12
+  - Check return value of virtualenvwrapper_verify_workon_home everywhere, thanks to 
+    Jeff Forcier for pointing out the errors.
+  - Fix instructions at top of README, pointed out by Matthew Scott.
+  - Add cdvirtualenv and cdsitepackages, contributed by James Bennett.
+  - Enhance test.sh.
+
+1.11
+  - Optimize virtualenvwrapper_show_workon_options.
+  - Add global postactivate hook.
+
+1.10
+  - Pull in fix for colorized ls from Jeff Forcier (b42a25f7b74a).
+
+1.9
+  - Add more hooks for operations to run before and after creating or deleting environments based on changes from Chris Hasenpflug.
+
+1.8.1
+  - Corrected a problem with change to mkvirtualenv that lead to release 1.8 by using an alternate fix proposed by James in comments on release 1.4.
+
+1.8
+  - Fix for processing the argument list in mkvirtualenv from jorgevargas (BitBucket issue #1)
+
+1.7
+  - Move to bitbucket.org for hosting
+  - clean up TODO list and svn keywords
+  - add license section below
+
+1.6.1
+
+  - More zsh support (fixes to rmvirtualenv) from Byron Clark.
+
+1.6
+
+  - Add completion support for zsh, courtesy of Ted Leung.
+
+1.5
+
+  - Fix some issues with spaces in directory or env names.  They still don't really work with virtualenv, though.
+  - Added documentation for the postactivate and predeactivate scripts.
+
+1.4
+
+  - Includes a new .pth management function based on work contributed by James Bennett and Jannis Leidel.
+
+1.3.x
+
+  - Includes a fix for a nasty bug in rmvirtualenv identified by John Shimek.

File docs/en/hooks.rst

+===============================
+ Customizing Virtualenvwrapper
+===============================
+
+virtualenvwrapper adds several hook points you can use to change your
+settings, shell environment, or other configuration values when
+creating, deleting, or moving between environments. These hooks are
+exposed in two ways:
+
+.. toctree::
+   :maxdepth: 1
+
+   scripts
+   plugins

File docs/en/index.rst

+.. virtualenvwrapper documentation master file, created by
+   sphinx-quickstart on Thu May 28 22:35:13 2009.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+###########################
+virtualenvwrapper |release|
+###########################
+
+virtualenvwrapper is a set of extensions to Ian Bicking's `virtualenv
+<http://pypi.python.org/pypi/virtualenv>`_ tool.  The extensions
+include wrappers for creating and deleting virtual environments and
+otherwise managing your development workflow, making it easier to work
+on more than one project at a time without introducing conflicts in
+their dependencies.
+
+========
+Features
+========
+
+1. Organizes all of your virtual environments in one place.
+2. Wrappers for managing your virtual environments (create, delete,
+   copy).
+3. Use a single command to switch between environments.
+4. Tab completion for commands that take a virtual environment as
+   argument.
+5. User-configurable hooks for all operations (see :ref:`scripts`).
+6. Plugin system for more creating sharable extensions (see
+   :ref:`plugins`).
+
+============
+Introduction
+============
+
+The best way to explain the features virtualenvwrapper gives you is to
+show it in use.
+
+First, some initialization steps.  Most of this only needs to be done
+one time.  You will want to add the command to ``source
+/usr/local/bin/virtualenvwrapper.sh`` to your shell startup file,
+changing the path to virtualenvwrapper.sh depending on where it was
+installed by pip.
+
+::
+
+  $ pip install virtualenvwrapper
+  ...
+  $ export WORKON_HOME=~/Envs
+  $ mkdir -p $WORKON_HOME
+  $ source /usr/local/bin/virtualenvwrapper.sh
+  $ mkvirtualenv env1
+  Installing
+  distribute..........................................
+  ....................................................
+  ....................................................
+  ...............................done.
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/predeactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/postdeactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/preactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/postactivate  New python executable in env1/bin/python
+  (env1)$ ls $WORKON_HOME
+  env1 hook.log
+
+Now we can install some software into the environment.
+
+::
+
+  (env1)$ pip install django
+  Downloading/unpacking django
+    Downloading Django-1.1.1.tar.gz (5.6Mb): 5.6Mb downloaded
+    Running setup.py egg_info for package django
+  Installing collected packages: django
+    Running setup.py install for django
+      changing mode of build/scripts-2.6/django-admin.py from 644 to 755
+      changing mode of /Users/dhellmann/Envs/env1/bin/django-admin.py to 755
+  Successfully installed django
+
+We can see the new package with ``lssitepackages``::
+
+  (env1)$ lssitepackages
+  Django-1.1.1-py2.6.egg-info     easy-install.pth
+  distribute-0.6.10-py2.6.egg     pip-0.6.3-py2.6.egg
+  django                          setuptools.pth
+
+Of course we are not limited to a single virtualenv::
+
+  (env1)$ ls $WORKON_HOME
+  env1            hook.log
+  (env1)$ mkvirtualenv env2
+  Installing distribute...............................
+  ....................................................
+  ....................................................
+  ........... ...............................done.
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/predeactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/postdeactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/preactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/postactivate  New python executable in env2/bin/python
+  (env2)$ ls $WORKON_HOME
+  env1            env2            hook.log
+
+Switch between environments with ``workon``::
+
+  (env2)$ workon env1
+  (env1)$ echo $VIRTUAL_ENV
+  /Users/dhellmann/Envs/env1
+  (env1)$ 
+
+The ``workon`` command also includes tab completion for the
+environment names, and invokes customization scripts as an environment
+is activated or deactivated (see :ref:`scripts`).
+
+::
+
+  (env1)$ echo 'cd $VIRTUAL_ENV' >> $WORKON_HOME/postactivate
+  (env1)$ workon env2
+  (env2)$ pwd
+  /Users/dhellmann/Envs/env2
+
+:ref:`scripts-postmkvirtualenv` is run when a new environment is
+created, letting you automatically install commonly-used tools.
+
+::
+
+  (env2)$ echo 'pip install sphinx' >> $WORKON_HOME/postmkvirtualenv
+  (env3)$ mkvirtualenv env3
+  New python executable in env3/bin/python
+  Installing distribute...............................
+  ....................................................
+  ....................................................
+  ........... ...............................done.
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/predeactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/postdeactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/preactivate
+  virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/postactivate
+  Downloading/unpacking sphinx
+    Downloading Sphinx-0.6.5.tar.gz (972Kb): 972Kb downloaded
+    Running setup.py egg_info for package sphinx
+      no previously-included directories found matching 'doc/_build'
+  Downloading/unpacking Pygments>=0.8 (from sphinx)
+    Downloading Pygments-1.3.1.tar.gz (1.1Mb): 1.1Mb downloaded
+    Running setup.py egg_info for package Pygments
+  Downloading/unpacking Jinja2>=2.1 (from sphinx)
+    Downloading Jinja2-2.4.tar.gz (688Kb): 688Kb downloaded
+    Running setup.py egg_info for package Jinja2
+      warning: no previously-included files matching '*' found under directory 'docs/_build/doctrees'
+  Downloading/unpacking docutils>=0.4 (from sphinx)
+    Downloading docutils-0.6.tar.gz (1.4Mb): 1.4Mb downloaded
+    Running setup.py egg_info for package docutils
+  Installing collected packages: docutils, Jinja2, Pygments, sphinx
+    Running setup.py install for docutils
+    Running setup.py install for Jinja2
+    Running setup.py install for Pygments
+    Running setup.py install for sphinx
+      no previously-included directories found matching 'doc/_build'
+      Installing sphinx-build script to /Users/dhellmann/Envs/env3/bin
+      Installing sphinx-quickstart script to /Users/dhellmann/Envs/env3/bin
+      Installing sphinx-autogen script to /Users/dhellmann/Envs/env3/bin
+  Successfully installed docutils Jinja2 Pygments sphinx  (env3)$ 
+  (venv3)$ which sphinx-build
+  /Users/dhellmann/Envs/env3/bin/sphinx-build
+
+Through a combination of the existing functions defined by the core
+package (see :ref:`command`), third-party plugins (see
+:ref:`plugins`), and user-defined scripts (see :ref:`scripts`)
+virtualenvwrapper gives you a wide variety of opportunities to
+automate repetitive operations.
+
+=======
+Details
+=======
+
+.. toctree::
+   :maxdepth: 2
+
+   install
+   command_ref
+   hooks
+   tips
+   developers
+   extensions
+   history
+
+.. _references:
+
+==========
+References
+==========
+
+`virtualenv <http://pypi.python.org/pypi/virtualenv>`_, from Ian
+Bicking, is a pre-requisite to using these extensions.
+
+For more details, refer to the column I wrote for the May 2008 issue
+of Python Magazine: `virtualenvwrapper | And Now For Something
+Completely Different
+<http://www.doughellmann.com/articles/CompletelyDifferent-2008-05-virtualenvwrapper/index.html>`_.
+
+Rich Leland has created a short `screencast
+<http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/>`__
+showing off the features of virtualenvwrapper.
+
+=======
+License
+=======
+
+Copyright Doug Hellmann, All Rights Reserved
+
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose and without fee is hereby granted,
+provided that the above copyright notice appear in all copies and that
+both that copyright notice and this permission notice appear in
+supporting documentation, and that the name of Doug Hellmann not be
+used in advertising or publicity pertaining to distribution of the
+software without specific, written prior permission.
+
+DOUG HELLMANN DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+EVENT SHALL DOUG HELLMANN BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
+USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
+OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+PERFORMANCE OF THIS SOFTWARE.

File docs/en/install.rst

+============
+Installation
+============
+
+Basic Installation
+==================
+
+virtualenvwrapper should be installed using pip_::
+
+  $ pip install virtualenvwrapper
+
+You will want to install it into the global Python site-packages area,
+along with virtualenv.  You may need administrative privileges to do
+that.
+
+WORKON_HOME
+===========
+
+The variable ``WORKON_HOME`` tells virtualenvwrapper where to place
+your virtual environments.  The default is ``$HOME/.virtualenvs``.
+This directory must be created before using any virtualenvwrapper
+commands.
+
+.. _install-shell-config:
+
+Shell Startup File
+==================
+
+Add two lines to your shell startup file (``.bashrc``, ``.profile``,
+etc.) to set the location where the virtual environments should live
+and the location of the script installed with this package::
+
+    export WORKON_HOME=$HOME/.virtualenvs
+    source /usr/local/bin/virtualenvwrapper.sh
+
+After editing it, reload the startup file (e.g., run: ``source
+~/.bashrc``).
+
+Python Interpreter and $PATH
+============================
+
+During startup, ``virtualenvwrapper.sh`` finds the first ``python`` on
+the ``$PATH`` and remembers it to use later.  This eliminates any
+conflict as the ``$PATH`` changes, enabling interpreters inside
+virtual environments where virtualenvwrapper is not installed.
+Because of this behavior, it is important for the ``$PATH`` to be set
+**before** sourcing ``virtualenvwrapper.sh``.  For example::
+
+    export PATH=/usr/local/bin:$PATH
+    source /usr/local/bin/virtualenvwrapper.sh
+
+To override the ``$PATH`` search, set the variable
+``VIRTUALENVWRAPPER_PYTHON`` to the full path of the interpreter to
+use (also **before** sourcing ``virtualenvwrapper.sh``).  For
+example::
+
+    export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python
+    source /usr/local/bin/virtualenvwrapper.sh
+
+Quick-Start
+===========
+
+1. Run: ``workon``
+2. A list of environments, empty, is printed.
+3. Run: ``mkvirtualenv temp``
+4. A new environment, ``temp`` is created and activated.
+5. Run: ``workon``
+6. This time, the ``temp`` environment is included.
+
+Temporary Files
+===============
+
+virtualenvwrapper creates temporary files in ``$TMPDIR``.  If the
+variable is not set, it uses ``/tmp``.  To change the location of
+temporary files just for virtualenvwrapper, set
+``VIRTUALENVWRAPPER_TMPDIR``.
+
+Upgrading from 1.x
+==================
+
+The shell script containing the wrapper functions has been renamed in
+the 2.x series to reflect the fact that shells other than bash are
+supported.  In your startup file, change ``source
+/usr/local/bin/virtualenvwrapper_bashrc`` to ``source
+/usr/local/bin/virtualenvwrapper.sh``.
+
+.. _pip: http://pypi.python.org/pypi/pip

File docs/en/plugins.rst

+.. _plugins:
+
+===========================
+Extending Virtualenvwrapper
+===========================
+
+Long experience with home-grown solutions for customizing a
+development environment has proven how valuable it can be to have the
+ability to automate common tasks and eliminate persistent annoyances.
+Carpenters build jigs, software developers write shell scripts.
+virtualenvwrapper continues the tradition of encouraging a craftsman
+to modify their tools to work the way they want, rather than the other
+way around.
+
+Use the hooks provided to eliminate repetitive manual operations and
+streamline your development workflow.  For example, set up the
+:ref:`plugins-pre_activate` and :ref:`plugins-post_activate` hooks to
+trigger an IDE to load a project file to reload files from the last
+editing session, manage time-tracking records, or start and stop
+development versions of an application server.  Use the
+:ref:`plugins-initialize` hook to add entirely new commands and hooks
+to virtualenvwrapper.  And the :ref:`plugins-pre_mkvirtualenv` and
+:ref:`plugins-post_mkvirtualenv` hooks give you an opportunity to
+install basic requirements into each new development environment,
+initialize a source code control repository, or otherwise set up a new
+project.
+
+There are two ways to attach your code so that virtualenvwrapper will
+run it: End-users can use shell scripts or other programs for personal
+customization (see :ref:`scripts`).  Extensions can also be
+implemented in Python by using Distribute_ *entry points*, making it
+possible to share common behaviors between systems and developers.
+
+Defining an Extension
+=====================
+
+.. note::
+
+  Virtualenvwrapper is delivered with a plugin for creating and
+  running the user customization scripts
+  (:ref:`extensions-user_scripts`).  The examples below are taken from
+  the implementation of that plugin.
+
+Code Organization
+-----------------
+
+The Python package for ``virtualenvwrapper`` is a *namespace package*.
+That means multiple libraries can install code into the package, even
+if they are not distributed together or installed into the same
+directory.  Extensions can (optionally) use the ``virtualenvwrapper``
+namespace by setting up their source tree like:
+
+* virtualenvwrapper/
+
+  * __init__.py
+  * user_scripts.py
+
+And placing the following code in ``__init__.py``::
+
+    """virtualenvwrapper module
+    """
+
+    __import__('pkg_resources').declare_namespace(__name__)
+
+.. note::
+
+    Extensions can be loaded from any package, so using the
+    ``virtualenvwrapper`` namespace is not required.
+
+Extension API
+-------------
+
+After the package is established, the next step is to create a module
+to hold the extension code.  For example,
+``virtualenvwrapper/user_scripts.py``.  The module should contain the
+actual extension entry points.  Supporting code can be included, or
+imported from elsewhere using standard Python code organization
+techniques.
+
+The API is the same for every extension point.  Each uses a Python
+function that takes a single argument, a list of strings passed to the
+hook loader on the command line.  
+
+::
+
+    def function_name(args):
+        # args is a list of strings passed to the hook loader
+
+The contents of the argument list are defined for each extension point
+below (see :ref:`plugins-extension-points`).
+
+Extension Invocation
+--------------------
+
+Direct Action
+~~~~~~~~~~~~~
+
+Plugins can attach to each hook in two different ways.  The default is
+to have a function run and do some work directly.  For example, the
+``initialize()`` function for the user scripts plugin creates default
+user scripts when ``virtualenvwrapper.sh`` is loaded.
+
+::
+
+    def initialize(args):
+        for filename, comment in GLOBAL_HOOKS:
+            make_hook(os.path.join('$WORKON_HOME', filename), comment)
+        return 
+
+.. _plugins-user-env:
+
+Modifying the User Environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are cases where the extension needs to update the user's
+environment (e.g., changing the current working directory or setting
+environment variables).  Modifications to the user environment must be
+made within the user's current shell, and cannot be run in a separate
+process.  To have code run in the user's shell process, extensions can
+define hook functions to return the text of the shell statements to be
+executed.  These *source* hooks are run after the regular hooks with
+the same name, and should not do any work of their own.
+
+The ``initialize_source()`` hook for the user scripts plugin looks for
+a global initialize script and causes it to be run in the current
+shell process.
+
+::
+
+    def initialize_source(args):
+        return """
+    #
+    # Run user-provided scripts
+    #
+    [ -f "$WORKON_HOME/initialize" ] && source "$WORKON_HOME/initialize"
+    """
+
+.. warning::
+
+    Because the extension is modifying the user's working shell, care
+    must be taken not to corrupt the environment by overwriting
+    existing variable values unexpectedly.  Avoid creating temporary
+    variables where possible, and use unique names where variables
+    cannot be avoided.  Prefixing variables with the extension name is
+    a good way to manage the namespace.  For example, instead of
+    ``temp_file`` use ``user_scripts_temp_file``.  Use ``unset`` to
+    release temporary variable names when they are no longer needed.
+
+.. warning::
+
+    virtualenvwrapper works under several shells with slightly
+    different syntax (bash, sh, zsh, ksh).  Take this portability into
+    account when defining source hooks.  Sticking to the simplest
+    possible syntax usually avoids problems, but there may be cases
+    where examining the ``SHELL`` environment variable to generate
+    different syntax for each case is the only way to achieve the
+    desired result.
+    
+Registering Entry Points
+------------------------
+
+The functions defined in the plugin need to be registered as *entry
+points* in order for virtualenvwrapper's hook loader to find them.
+Distribute_ entry points are configured in the ``setup.py`` for your
+package by mapping the entry point name to the function in the package
+that implements it.
+
+This partial copy of virtualenvwrapper's ``setup.py`` illustrates how
+the ``initialize()`` and ``initialize_source()`` entry points are
+configured.
+
+::
+    
+    # Bootstrap installation of Distribute
+    import distribute_setup
+    distribute_setup.use_setuptools()
+    
+    from setuptools import setup
+    
+    setup(
+        name = 'virtualenvwrapper',
+        version = '2.0',
+        
+        description = 'Enhancements to virtualenv',
+    
+        # ... details omitted ...
+
+        namespace_packages = [ 'virtualenvwrapper' ],
+    
+        entry_points = {
+            'virtualenvwrapper.initialize': [
+                'user_scripts = virtualenvwrapper.user_scripts:initialize',
+                ],
+            'virtualenvwrapper.initialize_source': [
+                'user_scripts = virtualenvwrapper.user_scripts:initialize_source',
+                ],
+    
+            # ... details omitted ...
+            },
+        )
+
+The ``entry_points`` argument to ``setup()`` is a dictionary mapping
+the entry point *group names* to lists of entry point specifiers.  A
+different group name is defined by virtualenvwrapper for each
+extension point (see :ref:`plugins-extension-points`).
+
+The entry point specifiers are strings with the syntax ``name =
+package.module:function``.  By convention, the *name* of each entry
+point is the plugin name, but that is not required (the names are not
+used).
+
+.. seealso::
+
+  * `namespace packages <http://packages.python.org/distribute/setuptools.html#namespace-packages>`__
+  * `Extensible Applications and Frameworks <http://packages.python.org/distribute/setuptools.html#extensible-applications-and-frameworks>`__
+
+The Hook Loader
+---------------
+
+Extensions are run through a command line application implemented in
+``virtualenvwrapper.hook_loader``.  Because ``virtualenvwrapper.sh``
+is the primary caller and users do not typically need to run the app
+directly, no separate script is installed.  Instead, to run the
+application, use the ``-m`` option to the interpreter::
+
+  $ python -m virtualenvwrapper.hook_loader -h
+  Usage: virtualenvwrapper.hook_loader [options] <hook> [<arguments>]
+  
+  Manage hooks for virtualenvwrapper
+  
+  Options:
+    -h, --help            show this help message and exit
+    -s, --source          Print the shell commands to be run in the current
+                          shell
+    -l, --list            Print a list of the plugins available for the given
+                          hook
+    -v, --verbose         Show more information on the console
+    -q, --quiet           Show less information on the console
+    -n NAMES, --name=NAMES
+                          Only run the hook from the named plugin
+  
+To run the extensions for the initialize hook::
+
+  $ python -m virtualenvwrapper.hook_loader -v initialize
+
+To get the shell commands for the initialize hook::
+
+  $ python -m virtualenvwrapper.hook_loader --source initialize
+
+In practice, rather than invoking the hook loader directly it is more
+convenient to use the shell function, ``virtualenvwrapper_run_hook``
+to run the hooks in both modes.::
+
+  $ virtualenvwrapper_run_hook initialize
+
+All of the arguments given to shell function are passed directly to
+the hook loader.
+
+Logging
+-------
+
+The hook loader configures logging so that messages are written to
+``$WORKON_HOME/hook.log``.  Messages also may be written to stderr,
+depending on the verbosity flag.  The default is for messages at *info*
+or higher levels to be written to stderr, and *debug* or higher to go to
+the log file.  Using logging in this way provides a convenient
+mechanism for users to control the verbosity of extensions.
+
+To use logging from within your extension, simply instantiate a logger
+and call its ``info()``, ``debug()`` and other methods with the
+messages.
+
+::
+
+    import logging
+    log = logging.getLogger(__name__)
+
+    def pre_mkvirtualenv(args):
+        log.debug('pre_mkvirtualenv %s', str(args))
+        # ...
+
+.. seealso::
+
+   * `Standard library documentation for logging <http://docs.python.org/library/logging.html>`__
+   * `PyMOTW for logging <http://www.doughellmann.com/PyMOTW/logging/>`__
+
+.. _plugins-extension-points:
+
+Extension Points
+================
+
+The extension point names for native plugins follow a naming
+convention with several parts:
+``virtualenvwrapper.(pre|post)_<event>[_source]``.  The *<event>* is
+the action taken by the user or virtualenvwrapper that triggers the
+extension.  ``(pre|post)`` indicates whether to call the extension
+before or after the event.  The suffix ``_source`` is added for
+extensions that return shell code instead of taking action directly
+(see :ref:`plugins-user-env`).
+
+.. _plugins-initialize:
+
+initialize
+----------
+
+The ``virtualenvwrapper.initialize`` hooks are run each time
+``virtualenvwrapper.sh`` is loaded into the user's environment.  The
+initialize hook can be used to install templates for configuration
+files or otherwise prepare the system for proper plugin operation.
+
+.. _plugins-pre_mkvirtualenv:
+
+pre_mkvirtualenv
+----------------
+
+The ``virtualenvwrapper.pre_mkvirtualenv`` hooks are run after the
+virtual environment is created, but before the new environment is
+activated.  The current working directory for when the hook is run is
+``$WORKON_HOME`` and the name of the new environment is passed as an
+argument.
+
+.. _plugins-post_mkvirtualenv:
+
+post_mkvirtualenv
+-----------------
+
+The ``virtualenvwrapper.post_mkvirtualenv`` hooks are run after a new
+virtual environment is created and activated.  ``$VIRTUAL_ENV`` is set
+to point to the new environment.
+
+.. _plugins-pre_activate:
+
+pre_activate
+------------
+
+The ``virtualenvwrapper.pre_activate`` hooks are run just before an
+environment is enabled.  The environment name is passed as the first
+argument.
+
+.. _plugins-post_activate:
+
+post_activate
+-------------
+
+The ``virtualenvwrapper.post_activate`` hooks are run just after an
+environment is enabled.  ``$VIRTUAL_ENV`` is set to point to the
+current environment.
+
+.. _plugins-pre_deactivate:
+
+pre_deactivate
+--------------
+
+The ``virtualenvwrapper.pre_deactivate`` hooks are run just before an
+environment is disabled.  ``$VIRTUAL_ENV`` is set to point to the
+current environment.
+
+.. _plugins-post_deactivate:
+
+post_deactivate
+---------------
+
+The ``virtualenvwrapper.post_deactivate`` hooks are run just after an
+environment is disabled.  The name of the environment just deactivated
+is passed as the first argument.
+
+.. _plugins-pre_rmvirtualenv:
+
+pre_rmvirtualenv
+----------------
+
+The ``virtualenvwrapper.pre_rmvirtualenv`` hooks are run just before
+an environment is deleted.  The name of the environment being deleted
+is passed as the first argument.
+
+.. _plugins-post_rmvirtualenv:
+
+post_rmvirtualenv
+-----------------
+
+The ``virtualenvwrapper.post_rmvirtualenv`` hooks are run just after
+an environment is deleted.  The name of the environment being deleted
+is passed as the first argument.
+
+Adding New Extension Points
+===========================
+
+Plugins that define new operations can also define new extension
+points.  No setup needs to be done to allow the hook loader to find
+the extensions; documenting the names and adding calls to
+``virtualenvwrapper_run_hook`` is sufficient to cause them to be
+invoked.  
+
+The hook loader assumes all extension point names start with
+``virtualenvwrapper.`` and new plugins will want to use their own
+namespace qualifier to append to that.  For example, the project_
+extension defines new events around creating project directories (pre
+and post).  These are called
+``virtualenvwrapper.project.pre_mkproject`` and
+``virtualenvwrapper.project.post_mkproject``.  These are invoked
+with::
+
+  virtualenvwrapper_run_hook project.pre_mkproject $project_name
+
+and::
+
+  virtualenvwrapper_run_hook project.post_mkproject
+
+respectively.
+
+.. _Distribute: http://packages.python.org/distribute/
+
+.. _project: http://www.doughellmann.com/projects/virtualenvwrapper.project/

File docs/en/scripts.rst

+.. _scripts:
+
+========================
+ Per-User Customization
+========================
+
+The end-user customization scripts are either *sourced* (allowing them
+to modify your shell environment) or *run* as an external program at
+the appropriate trigger time.
+
+.. _scripts-initialize:
+
+initialize
+==========
+
+  :Global/Local: global
+  :Argument(s): None
+  :Sourced/Run: sourced
+
+``$WORKON_HOME/initialize`` is sourced when ``virtualenvwrapper.sh``
+is loaded into your environment.  Use it to adjust global settings
+when virtualenvwrapper is enabled.
+
+.. _scripts-premkvirtualenv:
+
+premkvirtualenv
+===============
+
+  :Global/Local: global
+  :Argument(s): name of new environment
+  :Sourced/Run: run
+
+``$WORKON_HOME/premkvirtualenv`` is run as an external program after
+the virtual environment is created but before the current environment
+is switched to point to the new env. The current working directory for
+the script is ``$WORKON_HOME`` and the name of the new environment is
+passed as an argument to the script.
+
+.. _scripts-postmkvirtualenv:
+
+postmkvirtualenv
+================
+
+  :Global/Local: global
+  :Argument(s): none
+  :Sourced/Run: sourced
+
+``$WORKON_HOME/postmkvirtualenv`` is sourced after the new environment
+is created and activated.
+
+.. _scripts-precpvirtualenv:
+
+precpvirtualenv
+===============
+
+  :Global/Local: global
+  :Argument(s): name of original environment, name of new environment
+  :Sourced/Run: run
+
+``$WORKON_HOME/precpvirtualenv`` is run as an external program after
+the source environment is duplicated and made relocatable, but before
+the ``premkvirtualenv`` hook is run or the current environment is
+switched to point to the new env. The current working directory for
+the script is ``$WORKON_HOME`` and the names of the source and new
+environments are passed as arguments to the script.
+
+.. _scripts-postcpvirtualenv:
+
+postcpvirtualenv
+================
+
+  :Global/Local: global
+  :Argument(s): none
+  :Sourced/Run: sourced
+
+``$WORKON_HOME/postcpvirtualenv`` is sourced after the new environment
+is created and activated.
+
+.. _scripts-preactivate:
+
+preactivate
+===========
+
+  :Global/Local: global, local
+  :Argument(s): environment name
+  :Sourced/Run: run
+
+The global ``$WORKON_HOME/preactivate`` script is run before the new
+environment is enabled.  The environment name is passed as the first
+argument.
+
+The local ``$VIRTUAL_ENV/bin/preactivate`` hook is run before the new
+environment is enabled.  The environment name is passed as the first
+argument.
+
+.. _scripts-postactivate:
+
+postactivate
+============
+
+  :Global/Local: global, local
+  :Argument(s): none
+  :Sourced/Run: sourced
+
+The global ``$WORKON_HOME/postactivate`` script is sourced after the
+new environment is enabled. ``$VIRTUAL_ENV`` refers to the new
+environment at the time the script runs.
+
+This example script adds a space between the virtual environment name
+and your old PS1 by making use of ``_OLD_VIRTUAL_PS1``.
+
+::
+
+    PS1="(`basename \"$VIRTUAL_ENV\"`) $_OLD_VIRTUAL_PS1"
+
+The local ``$VIRTUAL_ENV/bin/postactivate`` script is sourced after
+the new environment is enabled. ``$VIRTUAL_ENV`` refers to the new
+environment at the time the script runs.
+
+This example script for the PyMOTW environment changes the current
+working directory and the PATH variable to refer to the source tree
+containing the PyMOTW source.
+
+::
+
+    pymotw_root=/Users/dhellmann/Documents/PyMOTW
+    cd $pymotw_root
+    PATH=$pymotw_root/bin:$PATH
+
+.. _scripts-predeactivate:
+
+predeactivate
+=============
+
+  :Global/Local: local, global
+  :Argument(s): none
+  :Sourced/Run: sourced
+
+The local ``$VIRTUAL_ENV/bin/predeactivate`` script is sourced before the
+current environment is deactivated, and can be used to disable or
+clear settings in your environment. ``$VIRTUAL_ENV`` refers to the old
+environment at the time the script runs.
+
+The global ``$WORKON_HOME/predeactivate`` script is sourced before the
+current environment is deactivated.  ``$VIRTUAL_ENV`` refers to the
+old environment at the time the script runs.
+
+.. _scripts-postdeactivate:
+
+postdeactivate
+==============
+
+  :Global/Local: local, global
+  :Argument(s): none
+  :Sourced/Run: sourced
+
+The ``$VIRTUAL_ENV/bin/postdeactivate`` script is sourced after the
+current environment is deactivated, and can be used to disable or
+clear settings in your environment.  The path to the environment just
+deactivated is available in ``$VIRTUALENVWRAPPER_LAST_VIRTUALENV``.
+
+.. _scripts-prermvirtualenv:
+
+prermvirtualenv
+===============
+
+  :Global/Local: global
+  :Argument(s): environment name
+  :Sourced/Run: run
+
+The ``$WORKON_HOME/prermvirtualenv`` script is run as an external
+program before the environment is removed. The full path to the
+environment directory is passed as an argument to the script.
+
+.. _scripts-postrmvirtualenv:
+
+postrmvirtualenv
+================
+
+  :Global/Local: global
+  :Argument(s): environment name
+  :Sourced/Run: run
+
+The ``$WORKON_HOME/postrmvirtualenv`` script is run as an external
+program after the environment is removed. The full path to the
+environment directory is passed as an argument to the script.

File docs/en/tips.rst

+.. _tips-and-tricks:
+
+=================
+ Tips and Tricks
+=================
+
+This is a list of user-contributed tips for making virtualenv and
+virtualenvwrapper even more useful.  If you have tip to share, drop me
+an email or post a comment on `this blog post
+<http://blog.doughellmann.com/2010/01/virtualenvwrapper-tips-and-tricks.html>`__
+and I'll add it here.
+
+zsh Prompt
+==========
+
+From `Nat <http://www.blogger.com/profile/16779944428406910187>`_:
+
+Using zsh, I added some bits to ``$WORKON_HOME/post(de)activate`` to show
+the active virtualenv on the right side of my screen instead.
+
+in ``postactivate``::
+
+    PS1="$_OLD_VIRTUAL_PS1"
+    _OLD_RPROMPT="$RPROMPT"
+    RPROMPT="%{${fg_bold[white]}%}(env: %{${fg[green]}%}`basename \"$VIRTUAL_ENV\"`%{${fg_bold[white]}%})%{${reset_color}%} $RPROMPT"
+
+and in ``postdeactivate``::
+
+    RPROMPT="$_OLD_RPROMPT"
+
+Adjust colors according to your own personal tastes or environment.
+
+Updating cached ``$PATH`` entries
+=================================
+
+From `Nat <http://www.blogger.com/profile/16779944428406910187>`_:
+
+I also added the command 'rehash' to ``$WORKON_HOME/postactivate`` and
+``$WORKON_HOME/postdeactivate`` as I was having some problems with zsh
+not picking up the new paths immediately.
+
+Tying to pip's virtualenv support
+=================================
+
+Via http://becomingguru.com/:
+
+Add this to your shell login script to make pip use the same directory
+for virtualenvs as virtualenvwrapper::
+
+    export PIP_VIRTUALENV_BASE=$WORKON_HOME
+
+and Via Nat:
+
+in addition to what becomingguru said, this line is key::
+
+   export PIP_RESPECT_VIRTUALENV=true
+
+That makes pip detect an active virtualenv and install to it, without
+having to pass it the -E parameter.
+
+Creating Project Work Directories
+=================================
+
+Via `James <http://www.blogger.com/profile/02618224969192901883>`_:
+
+In the ``postmkvirtualenv`` script I have the following to create a
+directory based on the project name, add that directory to the python
+path and then cd into it::
+
+    proj_name=$(echo $VIRTUAL_ENV|awk -F'/' '{print $NF}')
+    mkdir $HOME/projects/$proj_name
+    add2virtualenv $HOME/projects/$proj_name
+    cd $HOME/projects/$proj_name
+
+
+In the ``postactivate`` script I have it set to automatically change
+to the project directory when I use the workon command::
+
+    proj_name=$(echo $VIRTUAL_ENV|awk -F'/' '{print $NF}')
+    cd ~/projects/$proj_name
+
+Automatically Run workon When Entering a Directory
+==================================================
+
+`Justin Lily posted
+<http://justinlilly.com/blog/2009/mar/28/virtualenv-wrapper-helper/>`__
+about some code he added to his shell environment to look at the
+directory each time he runs ``cd``.  If it finds a ``.venv`` file, it
+activates the environment named within.  On leaving that directory,
+the current virtualenv is automatically deactivated.
+
+`Harry Marr <http://www.blogger.com/profile/17141199633387157732>`__
+wrote a similar function that works with `git repositories
+<http://hmarr.com/2010/jan/19/making-virtualenv-play-nice-with-git/>`__.
+
+Installing Common Tools Automatically in New Environments
+=========================================================
+
+Via `rizumu <http://rizumu.myopenid.com/>`__:
+
+I have this ``postmkvirtualenv`` to install the get a basic setup.
+
+::
+
+    $ cat postmkvirtualenv
+    #!/usr/bin/env bash
+    curl -O http://python-distribute.org/distribute_setup.p... />python distribute_setup.py
+    rm distribute_setup.py
+    easy_install pip==dev
+    pip install Mercurial
+
+Then I have a pip requirement file with my dev tools.
+
+::
+
+    $ cat developer_requirements.txt
+    ipdb
+    ipython
+    pastescript
+    nose
+    http://douglatornell.ca/software/python/Nosy-1.0.tar.gz
+    coverage
+    sphinx
+    grin
+    pyflakes
+    pep8
+
+Then each project has it's own pip requirement file for things like
+PIL, psycopg2, django-apps, numpy, etc.
+
+Changing the Default Behavior of ``cd``
+=======================================
+
+Via `mae <http://www.blogger.com/profile/10879711379090472478>`__:
+
+This is supposed to be executed after workon, that is as a
+``postactivate`` hook. It basically overrides ``cd`` to know about the
+VENV so instead of doing ``cd`` to go to ``~`` you will go to the venv
+root, IMO very handy and I can't live without it anymore. if you pass
+it a proper path then it will do the right thing.
+
+::
+
+    cd () {
+        if (( $# == 0 ))
+        then
+            builtin cd $VIRTUAL_ENV
+        else
+            builtin cd "$@"
+        fi
+    }
+
+    cd

File docs/es/command_ref.rst

+.. Quick reference documentation for virtualenvwrapper command line functions
+    Originally contributed Thursday, May 28, 2009 by Steve Steiner (ssteinerX@gmail.com)
+
+.. _command:
+
+######################
+Referencia de comandos
+######################
+
+Todos los comandos, mostrados a continuación, son para ser utilizados 
+en una Terminal de línea de comandos.
+
+====================
+Administrar entornos
+====================
+
+.. _command-mkvirtualenv:
+
+mkvirtualenv
+------------
+
+Crea un nuevo entorno, dentro de WORKON_HOME.
+
+Sintaxis::
+
+    mkvirtualenv [options] ENVNAME
+
+Todas las opciones de línea de comandos son pasados directamente a
+``virtualenv``. El nuevo entorno es automáticamente activado luego de su
+inicialización.
+
+::
+
+    $ workon
+    $ mkvirtualenv mynewenv
+    New python executable in mynewenv/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (mynewenv)$ workon
+    mynewenv
+    (mynewenv)$ 
+
+.. seealso::
+
+   * :ref:`scripts-premkvirtualenv`
+   * :ref:`scripts-postmkvirtualenv`
+
+rmvirtualenv
+------------
+
+Elimina un entorno, dentro de WORKON_HOME.
+
+Sintaxis::
+
+    rmvirtualenv ENVNAME
+
+Debes usar :ref:`command-deactivate` antes de eliminar el entorno actual.
+
+::
+
+    (mynewenv)$ deactivate
+    $ rmvirtualenv mynewenv
+    $ workon
+    $
+
+.. seealso::
+
+   * :ref:`scripts-prermvirtualenv`
+   * :ref:`scripts-postrmvirtualenv`
+
+.. _command-cpvirtualenv:
+
+cpvirtualenv
+------------
+
+Duplica un entorno, dentro de WORKON_HOME.
+
+Sintaxis::
+
+    cpvirtualenv ENVNAME TARGETENVNAME
+
+.. note::
+
+   El entorno creado por la operación de copia es hecho `reubicable
+   <http://virtualenv.openplans.org/#making-environments-relocatable>`__.
+
+::
+
+    $ workon 
+    $ mkvirtualenv source
+    New python executable in source/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (source)$ cpvirtualenv source dest
+    Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install relative
+    Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install-2.6 relative
+    Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/pip relative
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postdeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/preactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/predeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
+    (dest)$ workon 
+    dest
+    source
+    (dest)$ 
+
+.. seealso::
+
+   * :ref:`scripts-precpvirtualenv`
+   * :ref:`scripts-postcpvirtualenv`
+   * :ref:`scripts-premkvirtualenv`
+   * :ref:`scripts-postmkvirtualenv`
+
+==============================
+Controlar los entornos activos
+==============================
+
+workon
+------
+
+Lista o cambia el entorno de trabajo actual
+
+Sintaxis::
+
+    workon [environment_name]
+
+Si no se especifica el ``environment_name``, la lista de entornos disponibles es
+impresa en la salida estándar.
+
+::
+
+    $ workon 
+    $ mkvirtualenv env1
+      New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ mkvirtualenv env2
+    New python executable in env2/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env2)$ workon 
+    env1
+    env2
+    (env2)$ workon env1
+    (env1)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ workon env2
+    (env2)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env2
+    (env2)$ 
+
+
+.. seealso::
+
+   * :ref:`scripts-predeactivate`
+   * :ref:`scripts-postdeactivate`
+   * :ref:`scripts-preactivate`
+   * :ref:`scripts-postactivate`
+
+.. _command-deactivate:
+
+deactivate
+----------
+
+Cambia de un entorno virtual a la versión instalada de Python en el sistema.
+
+Sintaxis::
+
+    deactivate
+
+.. note::
+
+    Este comando es actualmente parte de virtualenv, pero es encapsulado para
+    proveer ganchos antes y después, al igual que workon hace para *activate*.
+
+::
+
+    $ workon 
+    $ echo $VIRTUAL_ENV
+
+    $ mkvirtualenv env1
+    New python executable in env1/bin/python
+    Installing distribute.............................................
+    ..................................................................
+    ..................................................................
+    done.
+    (env1)$ echo $VIRTUAL_ENV
+    /Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
+    (env1)$ deactivate
+    $ echo $VIRTUAL_ENV
+
+    $ 
+
+.. seealso::
+
+   * :ref:`scripts-predeactivate`
+   * :ref:`scripts-postdeactivate`
+
+======================================
+Rápida navegación dentro de virtualenv