Commits

Manuel Kaufmann committed 5545a04

Comments (0)

Files changed (9)

 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.
 
+**Cuidado:** La version 4.x incluye algunos cambios incompatibles con
+extensiones para 3.x. Los módulos de python para extensiones ahora
+corre *siempre* con ``PWD=$WORKON_HOME`` (anteriormente el valor de PWD
+variaba dependiendo del gancho). La porción de *shell* de cualquier gancho
+(cualquiera incluído por el shell del usuario cuando el gancho es ejecutado)
+es todavía ejecutado in el mismo lugar que antes.
+
+
 ===============
 Características
 ===============
 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/>`__
+<http://mathematism.com/2009/07/30/presentation-pip-and-virtualenv/>`__
 mostrando las características de virtualenvwrapper.
 
 
 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
-====================
+Shells soportados
+=================
 
-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``.
+virtualenvwrapper es un conjunto de *funciones* de shell definidas en sintaxis
+compatible con Bourne shell. Ha sido testeado bajo ``bash``, ``ksh`` y
+``zsh``. Quizás funcione con otros shells, así que si encuentras que funciona
+con otro shell que no esté listado aquí, por favor, házmelo saber. Si puedes
+modificarlo para que funcione con otro shell, sin re-escribirlo completamente,
+envíame a "pull request" a través de la página del proyecto de bitbucket. Si
+escribes un clon para que funcione con un shell incompatible, házmelo saber y
+voy a linkerlo desde ésta página.
 
-==============
-Contribuciones
+Versiones de Python
+===================
+
+virtualenvwrapper está probado bajo Python 2.6 - 3.3.
+
+=======
+Soporte
+=======
+
+Únete al grupo de `virtualenvwrapper en Google Groups
+<http://groups.google.com/group/virtualenvwrapper/>`__ para discutir
+problemas y mejoras.
+
+Reporta los bugs a través del `bug tracker de BitBucket
+<http://bitbucket.org/dhellmann/virtualenvwrapper/>`__
+
+Alias de shell
 ==============
 
-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.
+Debido a que virtualenvwrapper es mayormente un script de shell, éste usa
+comandos de shell para mucha de sus acciones. Si tu entorno hace mucho uso
+de alias de shell u otras personalizaciones, quizás encuentres algunos
+problemas. Antes de reportar bugs en el bug tracker, por favor prueba *sin*
+tus alias activadas. Si puedes identificar cuál es el alias que causa el
+problema, eso hará virtualenvwrapper más robusto.
 
-Ve a la `documentación para desarrolladores 
-<http://www.doughellmann.com/docs/virtualenvwrapper/developers.html>`__
-por trucos sobre parches.
+==========
+Change Log
+==========
+
+El `historial de versiones`_ es parte del proyecto de documentación.
+
+.. _release history: http://www.doughellmann.com/docs/virtualenvwrapper/history.html````
 
 ========
 Licencia
+=======================
+ virtualenvwrapper 4.1
+=======================
+
+.. tags:: virtualenvwrapper release python
+
+¿Qué es virtualenvwrapper?
+==========================
+
+virtualenvwrapper_ es un conjunto de extensiones de virtualenv_. Las extensiones
+incluyen wrappers para la creación y eliminación de entornos virtuales y
+también el manejo de tus flujo de desarrollo, haciéndolo más fácil para trabajar
+con más de un proyecto al mismo tiempo sin introducir problemas de dependencias.
+
+¿Qué hay de nuevo?
+==================
+
+- Asegurar que todos los comandos del estilo ``$()`` que producen paths están
+  entre comillas; ticket 164.
+- Comando ``wipeenv`` agregado para eliminar todos los paquetes instalados en
+  el entorno virtual.
+- Permitir usuarios de ``virtualenvwrapper_lazy.sh`` extender la lista de
+  comandos API que lanzan los lazy-loader extendiendo
+  ``_VIRTUALENVWRAPPER_API``. Parche contribuído por John Purnell, ver ticket
+  188.
+- Corregida la detección de la opción ``--python`` de ``mkvirtualenv``.
+  Ticket 190.
+- Comando ``allvirtualenv`` agregado para ejecutar un comando a través de
+  todos los entornos virtuales. Sugerido por Dave Coutts en ticket 186.
+- Arreglado ``lsvirtualenv`` cuando hay espacioes en ``WORKON_HOME``.
+  Ticket 194.
+- Cambio a `pbr`_ para empaquetado.
+
+.. _pbr: https://github.com/openstack-dev/pbr
+
+Instalción
+==========
+
+Visita la página del proyecto de virtualenvwrapper_ para links de descarga e
+instruciones de instalación
+
+.. _virtualenv: http://pypi.python.org/pypi/virtualenv
+
+.. _virtualenvwrapper: http://virtualenvwrapper.readthedocs.org/en/latest/

docs/source/command_ref.rst

    * :ref:`scripts-postmkvirtualenv`
    * `requirements file format`_
 
-.. _requirements file format: http://www.pip-installer.org/en/latest/requirement-format.html
+.. _requirements file format: http://www.pip-installer.org/en/latest/requirements.html
 
 .. _command-mktmpenv:
 
 ser un entorno manejado con virtualenvwrapper o uno externo creado en
 otro lugar.
 
+.. warning::
+
+   Copiar un entorno virtual no está del todo soportado. Cada entorno
+   virtual tiene información sobre los paths hardcodeado dentro de él,
+   y quizás el código copiado no sepa actualizar un archivo en particular.
+   **Usar con cuidado.**
+
 Sintaxis::
 
     cpvirtualenv ENVNAME [TARGETENVNAME]
    * :ref:`scripts-premkvirtualenv`
    * :ref:`scripts-postmkvirtualenv`
 
+.. _command-allvirtualenv:
+
+allvirtualenv
+-------------
+
+Ejecuta un comando dentro de todos los entornos virtuales bajo WORKON_HOME.
+
+
+Sintaxis::
+
+    allvirtualenv command with arguments
+
+    Cada entorno virtual es activado, ejecutando los ganchos de activación,
+    el directorio de trabajo actual es cambiado al entorno virtual activado
+    y el comando es ejecutado. Los comandos no pueden modificar el estado del
+    shell actual, pero pueden modificar el entorno virtual.
+
+    ::
+
+      $ allvirtualenv pip install -U pip
+
+
 ==============================
 Controlar los entornos activos
 ==============================
     add2virtualenv directory1 directory2 ...
 
 A veces esto es útli para compartir paquetes instalados que no están en el
-directorio ``site-pacakges`` del sistema y no deben ser instalados en cada
+directorio ``site-packages`` del sistema y no deben ser instalados en cada
 entorno virtual. Una posible solución es crear enlaces simbólicos (*symlinks*)
 hacia el código dentro del directorio ``site-packages`` del entorno, pero
 también es fácil agregar a la variable PYTHONPATH directorios extras que están
 4. Un mensaje de uso y una lista de las rutas "extras" actuales es impreso.
 
 Los nombres de los directorios son agregados a un archivo llamado
-``virtualenv_path_extensions.pth`` dentro del directorio site-packages de este
+``_virtualenv_path_extensions.pth`` dentro del directorio site-packages de este
 entorno.
 
 *Basado en una contribución de James Bennett y Jannis Leidel.*
 
 Sintaxis::
 
-    mkproject [-t template] [virtualenv_options] ENVNAME
+    mkproject [-f|--force] [-t template] [virtualenv_options] ENVNAME
+
+-f, --force    Crea un entorno virtual incluso si el directorio del proyecto
+               ya existe
 
 La opción template puede repetirse varias veces para utilizar
 diferentes templates en la creación del proyecto. Los templates son
   * :ref:`scripts-premkproject`
   * :ref:`scripts-postmkproject`
 
+.. _command-setvirtualenvproject:
+
 setvirtualenvproject
 --------------------
 
 Cuando ningún argumento es pasado, se asume el virtualenv y el
 directorio activo.
 
-Cualquier número de virtualenvs puede referirse al mismo directorio de
+Cualquier número de entornos virtuales puede referirse al mismo directorio de
 proyecto, haciendo fácil cambiar entre versiones de Python o otras
 dependencias necesarias para testing.
 
 Sintaxis::
 
   cdproject
+
+===========================
+Manegar paquetes instalados
+===========================
+
+.. _command-wipeenv:
+
+wipeenv
+-------
+
+Elimina todos los paquetes de terceros instalados en el entorno virtual actual.
+
+Syntax::
+
+  wipeenv
+

docs/source/conf.py

 # virtualenvwrapper documentation build configuration file, created by
 # sphinx-quickstart on Thu May 28 22:35:13 2009.
 #
-# This file is execfile()d with the current directory set to its containing dir.
+# This file is execfile()d with the current directory set to its
+# containing dir.
 #
 # Note that not all possible configuration values are present in this
 # autogenerated file.
 # serve to show the default.
 
 import datetime
-import sys, os
 import subprocess
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 #sys.path.append(os.path.abspath('.'))
 
-# -- General configuration -----------------------------------------------------
+# -- General configuration ---------------------------------------------------
 
-# Add any Sphinx extension module names here, as strings. They can be extensions
-# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = [ 'sphinxcontrib.bitbucket' ]
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['sphinxcontrib.bitbucket']
 
 bitbucket_project_url = 'http://bitbucket.org/dhellmann/virtualenvwrapper/'
 
 # built documents.
 #
 # The short X.Y version.
-version = subprocess.check_output(['sh', '-c', 'cd ../..; python setup.py --version'])
+version = subprocess.check_output([
+    'sh', '-c',
+    'cd ../..; python setup.py --version',
+])
 version = version.strip()
 # The full version, including alpha/beta/rc tags.
 release = version
 # for source files.
 exclude_trees = ['_build']
 
-# The reST default role (used for this markup: `text`) to use for all documents.
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
 #default_role = None
 
 # If true, '()' will be appended to :func: etc. cross-reference text.
 #modindex_common_prefix = []
 
 
-# -- Options for HTML output ---------------------------------------------------
+# -- Options for HTML output -------------------------------------------------
 
 # The theme to use for HTML and HTML Help pages.  Major themes that come with
 # Sphinx are currently 'default' and 'sphinxdoc'.
 htmlhelp_basename = 'virtualenvwrapperdoc'
 
 
-# -- Options for LaTeX output --------------------------------------------------
+# -- Options for LaTeX output ------------------------------------------------
 
 # The paper size ('letter' or 'a4').
 #latex_paper_size = 'letter'
 #latex_font_size = '10pt'
 
 # Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title, author, documentclass [howto/manual]).
+# (source start file, target name, title, author, documentclass
+#  [howto/manual]).
 latex_documents = [
-  ('index', 'virtualenvwrapper.tex', u'virtualenvwrapper Documentation',
-   u'Doug Hellmann', 'manual'),
+    ('index', 'virtualenvwrapper.tex', u'virtualenvwrapper Documentation',
+     u'Doug Hellmann', 'manual'),
 ]
 
 # The name of an image file (relative to this directory) to place at the top of

docs/source/design.rst

+===================================================================
+ ¿Porqué virtualenvwrapper no está (mayormente) escrito en Python?
+===================================================================
+
+Si miras al código fuente de virtualenvwrapper vas a ver que las partes más
+interesante están implementadas como funciones de shell en
+``virtualenvwrapper.sh``. El gancho de carga es una aplicación Python, pero no
+hace mucho para manejar los entornos virtuales. Algunas de las preguntas más
+frecuentes sobre virtualenvwrapper son "¿Porqué no escribiste esto como un
+conjunto de programas Python" y "¿"as pensado en re-escribirlo en Python?".
+Durante mucho tiempo esas preguntas me han desconcertado, pero fue siempre
+obvio para mí que tenía que implementarlo de la forma que está. Pero ellos
+preguntaban lo suficientemente frecuente que siento la necesidad de explicarlo.
+
+tl;dr: POSIX hizo que lo haga
+=============================
+
+La elección del lenguaje de implementación de virtualenvwrapper fue hecha por
+razones pragmáticas en vez de filosóficas. Los comandos wrapper necesitan
+modificar el estado y entorno de los *procesos actuales de shell* del usuario,
+y la única forma de hacer eso es teniendo los comandos ejecutándose *dentro del
+shell*. Eso resulta en mi escribiendo virtualenvwrapper como un conjunto de
+funciones de shell, en vez de scripts de shell o incluso programas Python.
+
+¿De dónde vienen los procesos POSIX?
+====================================
+
+Los nuevos procesos POSIX son creados cuando un proceso existente invoca la
+llamada al sistema ``fork()``. El proceso invocador se convierte en "padre" del
+nuevo proceso "hijo" y el hijo es un clon del padre. El resultado
+*semántico* de ``fork()`` es que una nueva copia entera del proceso padre es
+creado. En la práctica, las optimizaciones son normalmente hechas para evitar
+copiar más memoria que la absolutamente necesaria (frecuentemente a través de
+sistemas copy-on-write). Pero para el propósito de esta explicación es
+suficiente pernsar en el hijo como una replica del padre.
+
+Las partes importantes del proceso padre que son copiadas incluyen memoria
+dinámica (la 'stack' y 'heap'), cosas estáticas (el código del programa),
+recursos como descriptores de archivos, y el *entorno de variables* exportado
+por el proceso padre. Heredar variables de entorno es un aspecto fundamental en la
+manera en que los programas POSIX pasan estado e información de configuraciones
+de uno a otro. Un padre puede establecer una serie de pares ``name=value``, los
+que son luego son pasados a el proceso hijo. El hijo puede acceder a ellas a
+través de funciones como ``getenv()``, ``setenv()`` (y en Python a través de
+``os.environ``).
+
+La elección de el térmito *heredar* para describir la forma en que las
+variables y sus contenidos son pasados del padre al hijo es significante.
+Aunque, un hijo puede cambiar su propio entorno, éste no puede directamente
+cambiar las configuraciones de entorno de su padre porque no hay una llamada al
+sistem para modificar configuraciones de entorno de los padres.
+
+Como el shell ejecuta un programa
+=================================
+
+Cuando un shell recive un comando para ser ejecutado, interactivamente o
+pasando un archivo de script, y determina que el comando está implementado en
+un archivo de programa separado, usa ``fork()`` para crear un nuevo proceso y
+luego dentro de ese proceso usa una de las funciones ``exec`` para empezar el
+programa especificado. El lenguaje en el cual el programa está escrito no hace
+ninguna diferencia en la decisión sobre el ``fork()``, entonces aunque el
+"programa" sea un script escrito en el lenguaje entendido por el shell actual,
+un nuevo proceso es creado.
+
+Por otro lado, si el shell decide que el comando es una *función*, entonces se
+fija en la definición y la invoca diréctamente. Las funciones de shell están
+hechas de otros comandos, algunos de los cuales quizás resulten en la creación
+de procesos hijos, pero la función en sí misma se ejecuta en el proceso de
+shell original y puede por lo tanto modificar su estado, por ejemplo cambiando
+el directorio de trabajo o los valores de las variables.
+
+Es posible fozar al shell a ejecutar un script directamente, y no en un proceso
+hijo, *incluyéndolo*. El comando ``source`` hace que el shell lea el archivo e
+interprete éste en el proceso actual. De nuevo, como con las funciones, el
+contenido del archivo puede causar que procesos hijos sean creados, pero no hay
+un segundo shell interpretando la serie de comandos.
+
+¿Qué significa ésto para virtualenvwrapper?
+===========================================
+
+Lo original y más importante característica de virtualenvwrapper son la
+activación automática de un entorno virtual cuando éste es creado por el
+comando ``mkvirtualenv`` y usando ``workon`` para desactivar un entorno y
+activar otro. Hacer que esas características funcionen llevó a las decisiones
+de implementación de las otras partes de virtualenvwrapper, también.
+
+Los entornos son activados interactivamente incluyendo ``bin/source`` dentro
+del entorno. El script ``activate`` hace algunas cosas, pero las partes
+importantes son setear la variable ``VIRTUAL_ENV`` y modificar la ruta de
+búsqueda del shell a través de la variable ``PATH`` para poner el directorio
+``bin`` del entorno en frente del path. Cambiar el path significa que los
+programas instalados dentro del entorno, especialmente el intérprete de python
+de ahí, son encontrados antes que otros programas con el mismo nombre.
+
+Simplemente ejecutando ``bin/activate``, sin usar ``source`` no funciona porque
+éste configura el entorno de los procesos *hijos*, sin afectar al padre. Para
+incluir el script de activación en el shell interactivo, ambos ``mkvirtualenv``
+y ``workon`` necesitan ser ejecutados en ese proceso de shell.
+
+¿Porqué elegir uno cuando tienes ambos?
+=======================================
+
+El cargador de ganchos es una parte de virtualenvwrapper que *está* escrita en
+Python. ¿Porqué? De nuevo, porque es más fácil. Los ganchos son descubiertos
+usando puntos de entrada de setuptools, porque después de que un punto de
+entrada es instalado el usuario no tiene que tomar ninguna otra acción para
+permitir al cargador descubrirlo y usarlo. Es fácil imaginar escribir un gancho
+para crear nuevos archivos en el sistema de archivos (instalando un paquete,
+instanciando un template, etc.).
+
+Como, entonces, hacen los ganchos corriendo en un proceso separado (el
+intérprete de Python) para modificar el entorno del shell y setear variables o
+cambiar el directorio de trabajo? Hacen trampa, por supuesto.
+
+Cada gancho definido por virtualenvwrapper actualmente representa dos ganchos.
+Primero, los ganchos para Python son ejecutados. Luego los ganchos "source" son
+ejecutados, y ellos *imprimen* una serie de comandos shell. Todos esos comandos
+son recolectados, guardados en un archivo temporal, y luego se le dice al shell
+que lo incluya.
+
+Desde sus comienzos el cargador de ganchos fue mucho más costoso que la mayoría
+de las otras acciones que virtualenvwrapper hace, por eso, estoy considerando
+hacer que su uso sea opcional. La mayoría de los usuarios personalizan los
+ganchos haciendo uso de scripts de shell (ya sea globalmente o dentro del
+entorno virtual). Encontra y ejecutando aquellos que pueden ser manejados por
+el shell fácilmente.
+
+Implicancia para compatibilidad en diferentes shells
+====================================================
+
+Además de las peticiones por una implementación completa en Python, la otra
+petición más común es soportar shells adicionales. fish_ sale a menudo, debido
+a varios usuarios de Windows únicamente. Los :ref:`supporte-shells` todos
+tienen en común suficiente sintaxis que hace que la misma implementación
+funcione para ellos. Soportar otros shells requriría re-escribir mucho, si no
+todo, de la lógica usando syntaxis alternativa -- esos otros shells son
+básicamente diferentes lenguajes de programación. Hasta cierto punto he tratado
+con los ports alentando a otros desarolladores a manejarlos y luego intentantdo
+linkearlos y promocionar los resultados.
+
+.. _fish: http://ridiculousfish.com/shell/
+
+No tan malo como parece
+=======================
+
+Aunque hay algunos desafíos especiales creados por el requerimiento de que los
+comandos corran dentro del shell interactivo del usuario (ver los muchos bugs
+reportados por usuarios quienes tienen algias en comandos comunes como ``rm`` y
+``cd``), usar el shell como un lenguaje de programación se sostiene bastante
+bien. Los shells están diseñados para buscar y ejecutar otros programas
+fácilmente, y específicamente para hacer fácil combinar una serie de programas
+pequeños para realizar operaciones mucho más complicadas. Como es lo que
+virtualenvwrapper está haciendo, es un encaje natura.
+
+.. seealso::
+
+  * `Advanced Programming in the UNIX Environment`_ by W. Richard
+    Stevens & Stephen A. Rago
+  * `Fork (operating system)`_ on Wikipedia
+  * `Environment variable`_ on Wikipedia
+  * `Linux implementation of fork()`_
+
+.. _Advanced Programming in the UNIX Environment: http://www.amazon.com/gp/product/0321637739/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0321637739&linkCode=as2&tag=hellflynet-20
+
+.. _Fork (operating system): http://en.wikipedia.org/wiki/Fork_(operating_system)
+
+.. _Environment variable: http://en.wikipedia.org/wiki/Environment_variable
+
+.. _Linux implementation of fork(): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c?id=refs/tags/v3.9-rc8#n1558
+

docs/source/developers.rst

 
 - Sphinx
 - docutils
+- sphinxcontrib-bitbucket
 
 Una vez que todas las herramientas están instaladas dentro de un virtualenv
 usando pip, ejecuta ``make html`` para generar la versión de HTML de la

docs/source/history.rst

 ===============
 
 dev
+===
+
+- Add ``tmp-`` prefix to temporary environment names created by
+  :ref:`command-mktmpenv`.
+- Fix some uses of ``cd`` that did not account for possible
+  aliasing. Contributed by Ismail Badawi (:bbuser:`ibadawi`).
+- Fix documentation for :ref:`command-allvirtualenv`, contributed by
+  Andy Dirnberger (:bbuser:`dirn`).
+- Add ``--force`` option to :ref:`command-mkproject`, contributed by
+  Clay McClure (:bbuser:`claymcclure`).
+
+4.1.1
+=====
+
+- Fix packaging issue with 4.1.
+
+4.1
+===
+
+- Ensure that all ``$()`` style commands that produce paths are
+  quoted. Addresses :bbissue:`164`.
+- Add :ref:`command-wipeenv` command for removing all packages
+  installed in the virtualenv.
+- Allow users of ``virtualenvwrapper_lazy.sh`` to extend the list of
+  API commands that trigger the lazy-loader by extending
+  ``_VIRTUALENVWRAPPER_API``. Patch contributed by John Purnell, see
+  :bbissue:`188`.
+- Fix detection of ``--python`` option to
+  :ref:`command-mkvirtualenv`. Resolves :bbissue:`190`.
+- Add :ref:`command-allvirtualenv` command to run a command across all
+  virtualenvs. Suggested by Dave Coutts in :bbissue:`186`.
+- Fix :ref:`command-lsvirtualenv` when there are spaces in
+  ``WORKON_HOME``. Resolves :bbissue:`194`.
+- Switch to `pbr`_ for packaging.
+
+.. _pbr: https://github.com/openstack-dev/pbr
+
+4.0
+===
+
+**Warning:** This release includes some potentially incompatible
+changes for extensions. The python modules for extensions are now
+*always* run with ``PWD=$WORKON_HOME`` (previously the value of PWD
+varied depending on the hook). The *shell* portion of any hook
+(anything sourced by the user's shell when the hook is run) is still
+run in the same place as before.
+
+- All tests pass under Python 2.6, 2.7, 3.2 and 3.3.
+- Fix the name of the script in an error message produced
+  by ``virtualenvwrapper_lazy.sh``. (Contributed by
+  :bbuser:`scottstvnsn`.)
+
+3.7.1
+=====
+
+  - Rename functions for generating help so they do not pollute the
+    global namespace, and especially so they do not interfere with tab
+    completion. Contributed by :bbuser:`davidszotten`.
+  - Fix an issue with listing project templates if none are
+    installed. (:bbissue:`179`)
+  - Fix an issue with the ``--python`` option to ``mkvirtualenv``
+    becoming *sticky* for future calls that do not explicitly specify
+    the option. (:bbissue:`178`)
+
+3.7
+===
+
+  - Improve tab-completion support for users of the lazy-loading
+    mode. (:bbuser:`upsuper`)
+  - Add ``--help`` option to ``mkproject``.
+  - Add ``--help`` option to ``workon``.
+  - Turn off logging from the hook loader by default, and replace
+    ``VIRTUALENVWRAPPER_LOG_DIR`` environment variable with
+    ``VIRTUALENVWRAPPER_LOG_FILE``. The rotating log behavior remains
+    the same. The motivation for this change is the race condition
+    caused by that rotating behavior, especially when the wrappers are
+    being used by users with different permissions and
+    umasks. (:bbissue:`152`)
+  - Use flake8_ for style checking.
+
+.. _flake8: https://pypi.python.org/pypi/flake8
+
+3.6.1
+=====
+
+  - Replace realpath with a more portable way of converting a relative
+    path to an absolute path, used with the ``--python`` option to
+    mkvirtualenv (contributed by Radu Voicilas, :bbuser:`rvoicilas`).
+  - Posted release to PyPI, resolving download redirect
+    issue. (:bbissue:`171` and :bbissue:`172`)
+
+3.6
+===
 
   - Switch to stevedore_ for plugin management
   - mkvirtualenv_help should use ``$VIRTUALENVWRAPPER_PYTHON`` instead
   - Fix issue with lazy-loader code under zsh (:bbissue:`144`).
   - Fix issue with ``noclobber`` option under zsh
     (:bbissue:`137`). Fix based on patch from :bbuser:`rob_b`.
+  - Fix documentation for ``add2virtualenv`` to show the correct name
+    for the file containing the new path entry. (contributed by
+    :bbuser:`rvoicilas`)
+  - Fix problem with ``virtualenvwrapper_show_workon_options`` under
+    zsh with ``chpwd`` functions that produce output. (:bbissue:`153`)
 
 .. _stevedore: http://pypi.python.org/pypi/stevedore
 
 3.5
+===
 
   - Rewrite :ref:`command-cpvirtualenv` to use `virtualenv-clone`_
     instead of making the new environment relocatable. Contributed by
 
 
 3.4
+===
 
   - Add :ref:`install-lazy-loader` option.
 
 3.3
+===
 
   - Clean up file permissions and remove shebangs from scripts not
     intended to be executed on the command line. (contributed by
   - Make whitespace consistent. (:bbuser:`agriffis`)
 
 3.2
+===
 
   - Make ``project_dir`` a local variable so that
     :ref:`command-cdproject` does not interfere with other variables
     contributions toward the fix.
 
 3.1
+===
 
   - Fix a problem with activation hooks when associating a new
     virtualenv with an existing project directory. (:bbissue:`122`)
     containing "special" characters such as ``&``. (:bbissue:`132`)
 
 3.0.1
+=====
 
   - Fix some packaging issues that made it more difficult to run the
     tests directly from the sdist package. (:bbissue:`126`)
 
 3.0
+===
 
   - Add Python 3 support, thanks in large part to the efforts of
     Daniel Kraus (:bbuser:`dakra`). Tested under Python 2.6, 2.7, and
     3.2.
 
 2.11.1
+======
 
   - Remove the initialization shortcut because it breaks tab
     completion in sub-shell environments like screen and
     tmux. (:bbissue:`121`)
 
 2.11
+====
 
   - Add ``-a`` option to :ref:`command-mkvirtualenv` to associate a
     new virtualenv with an existing project directory. Contributed by
     reported by :bbuser:`arthuralvim`)
 
 2.10.1
+======
 
   - Changed arguments to :ref:`command-mktmpenv` so it always creates
     an environment name for you. (:bbissue:`114` reported by
     :bbuser:`alex_gaynor`)
 
 2.10
+====
 
   - Incorporated patch to add ``-d`` option to
     :ref:`command-add2virtualenv`, contributed by :bbuser:`miracle2k`.
     zsh. (:bbissue:`111`)
 
 2.9
+===
 
   - Change the shell function shell definition syntax so that ksh will
     treat typeset-declared variables as local. No kidding.
     dependencies using a pip requirements file.
 
 2.8
+===
 
   - Use VIRTUALENVWRAPPER_VIRTUALENV in `cpvirtualenv` (:bbissue:`104`).
   - Add support for `MSYS <http://www.mingw.org/wiki/MSYS>`_
     H. (:bbuser:`noirbizarre`).
 
 2.7.2
+=====
 
   - Move setup code for tab completion later in the startup code so
     all of the needed variables are configured. (:bbissue:`97`)
   - Expand tab completion for zsh to work for all commands.
 
 2.7.1
+=====
 
   - When testing for WORKON_HOME during startup, dereference any
     symlink to make sure it is a directory.
     outside of a virtualenv).
 
 2.7
+===
 
   - Fix problem with space in WORKON_HOME path (:bbissue:`79`).
   - Fix problem with argument processing in lsvirtualenv under zsh
     (:bbissue:`85`).
 
 2.6.3
+=====
 
   - Hard-code the version information in the setup.py and conf.py
     scripts. This still doesn't work for http://readthedocs.org, since
     will make it easier to transition the docs to another site later.
 
 2.6.2
+=====
 
   - Attempted to make the doc build work with http://readthedocs.org.
   - Merged in `Japanese translation of the documentation
     (:ref:`VIRTUALENVWRAPPER_VIRTUALENV <variable-VIRTUALENVWRAPPER_VIRTUALENV>`).
 
 2.6.1
+=====
 
   - Fixed virtualenvwrapper_get_python_version (:bbissue:`73`).
 
 2.6
+===
 
   - Fixed a problem with hook script line endings under Cygwin
     (:bbissue:`68`).
     scripts in the Makefile.
 
 2.5.3
+=====
 
   - Point release uploaded to PyPI during outage on doughellmann.com.
 
 2.5.2
+=====
 
   - Apply patch from Zach Voase to fix :ref:`command-lsvirtualenv`
     under zsh. Resolves :bbissue:`64`.
 
 2.5.1
+=====
 
   - Make :ref:`command-workon` list brief environment details when run
     without argument, instead of full details.
 
 2.5
+===
 
   - Add :ref:`command-showvirtualenv` command.  Modify
     :ref:`command-lsvirtualenv` to make verbose output the default.
 
 2.4
+===
 
   - Add :ref:`command-lsvirtualenv` command with ``-l`` option to run
     :ref:`scripts-get_env_details` hook instead of always running it
     when :ref:`command-workon` has no arguments.
 
 2.3
+===
 
   - Added ``get_env_details`` hook.
 
 2.2.2
+=====
 
   - Integrate Fred Palmer's patch to escape more shell commands to
     avoid aliases.  Resolves :bbissue:`57`.
   - Fix a problem with running mkvirtualenv without arguments (:bbissue:`56`).
 
 2.2.1
+=====
 
   - Escape ``which`` calls to avoid aliases. Resolves :bbissue:`46`.
   - Integrate Manuel Kaufmann's patch to unset GREP_OPTIONS before
     :bbissue:`50`.
 
 2.2
+===
 
   - Switched hook loader execution to a form that works with Python
     2.4 to resolve :bbissue:`43`.
   - Added some debug instrumentation for :bbissue:`35`.
 
 2.1.1
+=====
 
   - Added `Spanish translation for the documentation
     <http://www.doughellmann.com/docs/virtualenvwrapper/es/>`__ via
     virtualenv under zsh.  See :bbissue:`42`.
 
 2.1
+===
 
   - Add support for ksh.  Thanks to Doug Latornell for doing the
     research on what needed to be changed.
     10KiB.
 
 2.0.2
+=====
 
   - Fixed :bbissue:`32`, making virtualenvwrapper.user_scripts compatible
     with Python 2.5 again.
 
 2.0.1
+=====
 
   - Fixed :bbissue:`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
   - 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 :bbissue:`21` for complete details.
 
 1.23
+====
 
   - Resolve a bug with the postmkvirtualenv hook not being run
     properly.  Refer to :bbissue:`19` and :bbissue:`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
   - 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
     :bbissue:`15`. Directory normalization was causing ``WORKON_HOME``
     characters in the output of ``pwd``.
 
 1.18
+====
 
   - Remove warning during installation if sphinxcontrib.paverutils is
     not installed. (:bbissue:`10`)
   - 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.
     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
     <http://shunit2.googlecode.com/>`_
 
 1.13
+====
 
   - Fix :bbissue:`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.
   - 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
     (:bbchangeset:`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 (:bbissue:`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.

docs/source/index.rst

    tips
    developers
    extensions
+   design
    history
 
 .. _references:
 .. note::
 
    Esta traducción fue realizada por `Manuel Kaufmann
-   <http://humitos.wordpress.com/>`__.
+   <http://blog.mkaufmann.com.ar/>`__.
 
 .. seealso::
 
-   * `La traducción al español <http://bitbucket.org/humitos/virtualenvwrapper-es-translation/>`__
+   * `La traducción al español <https://bitbucket.org/dhellmann/virtualenvwrapper-docs-es/>`__
 
    * The original `English version
      <http://www.doughellmann.com/docs/virtualenvwrapper/>`__ of the

docs/source/install.rst

 Versiones de Python
 ===================
 
-virtualenvwrapper está testeado bajo Python 2.4 - 2.7.
+virtualenvwrapper está testeado bajo Python 2.6-3.3.
 
 .. _install-basic:
 
 
    * :ref:`scripts`
 
-.. _variable-VIRTUALENVWRAPPER_LOG_DIR:
+.. _variable-VIRTUALENVWRAPPER_LOG_FILE:
 
 Ubicación de los logs de los ganchos
 ------------------------------------
 
-La variable ``VIRTUALENVWRAPPER_LOG_DIR`` le indica a
+La variable ``VIRTUALENVWRAPPER_LOG_FILE`` le indica a
 virtualenvwrapper dónde deben ser escritos los logs para los scripts
-de gancho. El lugar por omisión es ``$WORKON_HOME``.
+de gancho. El lugar por omisión es no logear desde los ganchos.
 
 .. _variable-VIRTUALENVWRAPPER_VIRTUALENV: