1. Doug Hellmann
  2. virtualenvwrapper-docs-es

Commits

Manuel Kaufmann  committed 5545a04
  • Participants
  • Parent commits 760e1c2
  • Branches default

Comments (0)

Files changed (9)

File README.txt

View file
  • Ignore whitespace
 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

File announce.rst

View file
  • Ignore whitespace
+=======================
+ 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/

File docs/source/command_ref.rst

View file
  • Ignore whitespace
    * :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
+

File docs/source/conf.py

View file
  • Ignore whitespace
 # 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

File docs/source/design.rst

View file
  • Ignore whitespace
+===================================================================
+ ¿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
+

File docs/source/developers.rst

View file
  • Ignore whitespace
 
 - 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

File docs/source/history.rst

View file
  • Ignore whitespace
 ===============
 
 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.

File docs/source/index.rst

View file
  • Ignore whitespace
    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

File docs/source/install.rst

View file
  • Ignore whitespace
 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: