Merge branch 'release/1.8'

AUTHORS.txt

@@ -18,6 +18,7 @@ Anatoly Techtonik
 Antonio Cuni
 Armin Ronacher
 Bradley Ayers
+Branden Rolston
 Cap Petschulat
 CBWhiz
 Chris McDonough

bin/refresh-support-files.py

@@ -23,8 +23,8 @@
     ('http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg', 'setuptools-0.6c11-py2.6.egg'),
     ('http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c11-py2.5.egg', 'setuptools-0.6c11-py2.5.egg'),
     ('http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c11-py2.4.egg', 'setuptools-0.6c11-py2.4.egg'),
-    ('http://pypi.python.org/packages/source/d/distribute/distribute-0.6.27.tar.gz', 'distribute-0.6.27.tar.gz'),
-    ('http://pypi.python.org/packages/source/p/pip/pip-1.1.tar.gz', 'pip-1.1.tar.gz'),
+    ('http://pypi.python.org/packages/source/d/distribute/distribute-0.6.28.tar.gz', 'distribute-0.6.28.tar.gz'),
+    ('http://pypi.python.org/packages/source/p/pip/pip-1.2.tar.gz', 'pip-1.2.tar.gz'),
 ]
 
 

docs/index.txt

@@ -52,6 +52,9 @@ environment that has its own installation directories, that doesn't
 share libraries with other virtualenv environments (and optionally
 doesn't access the globally installed libraries either).
 
+Usage
+-----
+
 The basic usage is::
 
     $ python virtualenv.py ENV
@@ -77,6 +80,110 @@ A new virtualenv also includes the `pip <http://pypi.python.org/pypi/pip>`_
 installer, so you can use ``ENV/bin/pip`` to install additional packages into
 the environment.
 
+
+activate script
+~~~~~~~~~~~~~~~
+
+In a newly created virtualenv there will be a ``bin/activate`` shell
+script. For Windows systems, activation scripts are provided for CMD.exe
+and Powershell.
+
+On Posix systems you can do::
+
+    $ source bin/activate
+
+This will change your ``$PATH`` so its first entry is the virtualenv's
+``bin/`` directory.  (You have to use ``source`` because it changes your
+shell environment in-place.) This is all it does; it's purely a
+convenience.  If you directly run a script or the python interpreter
+from the virtualenv's ``bin/`` directory (e.g.  ``path/to/env/bin/pip``
+or ``/path/to/env/bin/python script.py``) there's no need for
+activation.
+
+After activating an environment you can use the function ``deactivate`` to
+undo the changes to your ``$PATH``.
+
+The ``activate`` script will also modify your shell prompt to indicate
+which environment is currently active.  You can disable this behavior,
+which can be useful if you have your own custom prompt that already
+displays the active environment name.  To do so, set the
+``VIRTUAL_ENV_DISABLE_PROMPT`` environment variable to any non-empty
+value before running the ``activate`` script.
+
+On Windows you just do::
+
+    > \path\to\env\Scripts\activate
+
+And type `deactivate` to undo the changes.
+
+Based on your active shell (CMD.exe or Powershell.exe), Windows will use
+either activate.bat or activate.ps1 (as appropriate) to activate the
+virtual environment. If using Powershell, see the notes about code signing
+below.
+
+.. note::
+
+    If using Powershell, the ``activate`` script is subject to the
+    `execution policies`_ on the system. By default on Windows 7, the system's
+    excution policy is set to ``Restricted``, meaning no scripts like the
+    ``activate`` script are allowed to be executed. But that can't stop us
+    from changing that slightly to allow it to be executed.
+
+    In order to use the script, you have to relax your system's execution
+    policy to ``AllSigned``, meaning all scripts on the system must be
+    digitally signed to be executed. Since the virtualenv activation
+    script is signed by one of the authors (Jannis Leidel) this level of
+    the execution policy suffices. As an administrator run::
+
+        PS C:\> Set-ExecutionPolicy AllSigned
+
+    Then you'll be asked to trust the signer, when executing the script.
+    You will be prompted with the following::
+
+        PS C:\> virtualenv .\foo
+        New python executable in C:\foo\Scripts\python.exe
+        Installing setuptools................done.
+        Installing pip...................done.
+        PS C:\> .\foo\scripts\activate
+
+        Do you want to run software from this untrusted publisher?
+        File C:\foo\scripts\activate.ps1 is published by E=jannis@leidel.info,
+        CN=Jannis Leidel, L=Berlin, S=Berlin, C=DE, Description=581796-Gh7xfJxkxQSIO4E0
+        and is not trusted on your system. Only run scripts from trusted publishers.
+        [V] Never run  [D] Do not run  [R] Run once  [A] Always run  [?] Help
+        (default is "D"):A
+        (foo) PS C:\>
+
+    If you select ``[A] Always Run``, the certificate will be added to the
+    Trusted Publishers of your user account, and will be trusted in this
+    user's context henceforth. If you select ``[R] Run Once``, the script will
+    be run, but you will be prometed on a subsequent invocation. Advanced users
+    can add the signer's certificate to the Trusted Publishers of the Computer
+    account to apply to all users (though this technique is out of scope of this
+    document).
+
+    Alternatively, you may relax the system execution policy to allow running
+    of local scripts without verifying the code signature using the following::
+
+        PS C:\> Set-ExecutionPolicy RemoteSigned
+
+    Since the ``activate.ps1`` script is generated locally for each virtualenv,
+    it is not considered a remote script and can then be executed.
+
+.. _`execution policies`: http://technet.microsoft.com/en-us/library/dd347641.aspx
+
+The ``--system-site-packages`` Option
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you build with ``virtualenv --system-site-packages ENV``, your virtual
+environment will inherit packages from ``/usr/lib/python2.7/site-packages``
+(or wherever your global site-packages directory is).
+
+This can be used if you have control over the global site-packages directory,
+and you want to depend on the packages there.  If you want isolation from the
+global system, do not use this flag.
+
+
 Environment variables and configuration files
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -225,109 +332,9 @@ Here's a more concrete example of how you could use this::
 Another example is available `here
 <https://github.com/socialplanning/fassembler/blob/master/fassembler/create-venv-script.py>`_.
 
-activate script
-~~~~~~~~~~~~~~~
-
-In a newly created virtualenv there will be a ``bin/activate`` shell
-script. For Windows systems, activation scripts are provided for CMD.exe
-and Powershell.
-
-On Posix systems you can do::
-
-    $ source bin/activate
-
-This will change your ``$PATH`` to point to the virtualenv's ``bin/``
-directory.  (You have to use ``source`` because it changes your shell
-environment in-place.) This is all it does; it's purely a convenience.  If
-you directly run a script or the python interpreter from the virtualenv's
-``bin/`` directory (e.g.  ``path/to/env/bin/pip`` or
-``/path/to/env/bin/python script.py``) there's no need for activation.
-
-After activating an environment you can use the function ``deactivate`` to
-undo the changes to your ``$PATH``.
-
-The ``activate`` script will also modify your shell prompt to indicate
-which environment is currently active.  You can disable this behavior,
-which can be useful if you have your own custom prompt that already
-displays the active environment name.  To do so, set the
-``VIRTUAL_ENV_DISABLE_PROMPT`` environment variable to any non-empty
-value before running the ``activate`` script.
-
-On Windows you just do::
-
-    > \path\to\env\Scripts\activate
-
-And type `deactivate` to undo the changes.
-
-Based on your active shell (CMD.exe or Powershell.exe), Windows will use
-either activate.bat or activate.ps1 (as appropriate) to activate the
-virtual environment. If using Powershell, see the notes about code signing
-below.
-
-.. note::
-
-    If using Powershell, the ``activate`` script is subject to the
-    `execution policies`_ on the system. By default on Windows 7, the system's
-    excution policy is set to ``Restricted``, meaning no scripts like the
-    ``activate`` script are allowed to be executed. But that can't stop us
-    from changing that slightly to allow it to be executed.
-
-    In order to use the script, you have to relax your system's execution
-    policy to ``AllSigned``, meaning all scripts on the system must be
-    digitally signed to be executed. Since the virtualenv activation
-    script is signed by one of the authors (Jannis Leidel) this level of
-    the execution policy suffices. As an administrator run::
-
-        PS C:\> Set-ExecutionPolicy AllSigned
-
-    Then you'll be asked to trust the signer, when executing the script.
-    You will be prompted with the following::
-
-        PS C:\> virtualenv .\foo
-        New python executable in C:\foo\Scripts\python.exe
-        Installing setuptools................done.
-        Installing pip...................done.
-        PS C:\> .\foo\scripts\activate
-
-        Do you want to run software from this untrusted publisher?
-        File C:\foo\scripts\activate.ps1 is published by E=jannis@leidel.info,
-        CN=Jannis Leidel, L=Berlin, S=Berlin, C=DE, Description=581796-Gh7xfJxkxQSIO4E0
-        and is not trusted on your system. Only run scripts from trusted publishers.
-        [V] Never run  [D] Do not run  [R] Run once  [A] Always run  [?] Help
-        (default is "D"):A
-        (foo) PS C:\>
-
-    If you select ``[A] Always Run``, the certificate will be added to the
-    Trusted Publishers of your user account, and will be trusted in this
-    user's context henceforth. If you select ``[R] Run Once``, the script will
-    be run, but you will be prometed on a subsequent invocation. Advanced users
-    can add the signer's certificate to the Trusted Publishers of the Computer
-    account to apply to all users (though this technique is out of scope of this
-    document).
-
-    Alternatively, you may relax the system execution policy to allow running
-    of local scripts without verifying the code signature using the following::
-
-        PS C:\> Set-ExecutionPolicy RemoteSigned
-
-    Since the ``activate.ps1`` script is generated locally for each virtualenv,
-    it is not considered a remote script and can then be executed.
-
-.. _`execution policies`: http://technet.microsoft.com/en-us/library/dd347641.aspx
-
-The ``--system-site-packages`` Option
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you build with ``virtualenv --system-site-packages ENV``, your virtual
-environment will inherit packages from ``/usr/lib/python2.7/site-packages``
-(or wherever your global site-packages directory is).
-
-This can be used if you have control over the global site-packages directory,
-and you want to depend on the packages there.  If you want isolation from the
-global system, do not use this flag.
 
 Using Virtualenv without ``bin/python``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 Sometimes you can't or don't want to use the Python interpreter
 created by the virtualenv.  For instance, in a `mod_python
@@ -353,7 +360,7 @@ request; you should activate *one* environment as early as possible, and not
 do it again in that process.
 
 Making Environments Relocatable
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Note: this option is somewhat experimental, and there are probably
 caveats that have not yet been identified.  Also this does not
@@ -390,8 +397,8 @@ layout).
 If you use this flag to create an environment, currently, the
 ``--system-site-packages`` option will be implied.
 
-The ``--extra-search-dir`` Option
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The ``--extra-search-dir`` option
+---------------------------------
 
 When it creates a new environment, virtualenv installs either
 setuptools or distribute, and pip.  In normal operation, the latest

docs/news.txt

@@ -15,6 +15,36 @@ Changes & News
    with the upgraded Python.
 
 
+1.8 (2012-09-01)
+~~~~~~~~~~~~~~~~
+
+* **Dropped support for Python 2.4** The minimum supported Python version is
+  now Python 2.5.
+
+* Fix `--relocatable` on systems that use lib64. Fixes #78. Thanks Branden
+  Rolston.
+
+* Symlink some additional modules under Python 3. Fixes #194. Thanks Vinay
+  Sajip, Ian Clelland, and Stefan Holek for the report.
+
+* Fix ``--relocatable`` when a script uses ``__future__`` imports. Thanks
+  Branden Rolston.
+
+* Fix a bug in the config option parser that prevented setting negative
+  options with environemnt variables. Thanks Ralf Schmitt.
+
+* Allow setting ``--no-site-packages`` from the config file.
+
+* Use ``/usr/bin/multiarch-platform`` if available to figure out the include
+  directory. Thanks for the patch, Mika Laitio.
+
+* Fix ``install_name_tool`` replacement to work on Python 3.X.
+
+* Handle paths of users' site-packages on Mac OS X correctly when changing
+  the prefix.
+
+* Updated the embedded version of distribute to 0.6.28 and pip to 1.2.
+
 1.7.2 (2012-06-22)
 ~~~~~~~~~~~~~~~~~~
 
@@ -344,7 +374,7 @@ Changes & News
   ``distutils.cfg`` -- this has been causing problems for a lot of
   people, in rather obscure ways.
 
-* If you use a `boot script <./index.html#boot-script>`_ it will attempt to import ``virtualenv``
+* If you use a boot script it will attempt to import ``virtualenv``
   and find a pre-downloaded Setuptools egg using that.
 
 * Added platform-specific paths, like ``/usr/lib/pythonX.Y/plat-linux2``

setup.py

@@ -71,7 +71,6 @@ def get_version():
         'Intended Audience :: Developers',
         'License :: OSI Approved :: MIT License',
         'Programming Language :: Python :: 2',
-        'Programming Language :: Python :: 2.4',
         'Programming Language :: Python :: 2.5',
         'Programming Language :: Python :: 2.6',
         'Programming Language :: Python :: 2.7',

tests/test_activate.sh

@@ -17,7 +17,7 @@ fi
 echo "$0: Created virtualenv ${TESTENV}." 1>&2
 
 echo "$0: Activating ${TESTENV}..." 1>&2
-source ${TESTENV}/bin/activate
+. ${TESTENV}/bin/activate
 echo "$0: Activated ${TESTENV}." 1>&2
 
 echo "$0: Checking value of \$VIRTUAL_ENV..." 1>&2

tests/test_virtualenv.py

@@ -1,4 +1,5 @@
 import virtualenv
+import optparse
 from mock import patch, Mock
 
 
@@ -48,3 +49,46 @@ def test_resolve_intepreter_with_invalid_interpreter(mock_exists):
 
     mock_exists.assert_called_with("/usr/bin/python42")
     virtualenv.is_executable.assert_called_with("/usr/bin/python42")
+
+
+def test_activate_after_future_statements():
+    """Should insert activation line after last future statement"""
+    script = [
+        '#!/usr/bin/env python',
+        'from __future__ import with_statement',
+        'from __future__ import print_function',
+        'print("Hello, world!")'
+    ]
+    assert virtualenv.relative_script(script) == [
+        '#!/usr/bin/env python',
+        'from __future__ import with_statement',
+        'from __future__ import print_function',
+        '',
+        "import os; activate_this=os.path.join(os.path.dirname(os.path.realpath(__file__)), 'activate_this.py'); execfile(activate_this, dict(__file__=activate_this)); del os, activate_this",
+        '',
+        'print("Hello, world!")'
+    ]
+
+
+def test_cop_update_defaults_with_store_false():
+    """store_false options need reverted logic"""
+    class MyConfigOptionParser(virtualenv.ConfigOptionParser):
+        def __init__(self, *args, **kwargs):
+            self.config = virtualenv.ConfigParser.RawConfigParser()
+            self.files = []
+            optparse.OptionParser.__init__(self, *args, **kwargs)
+
+        def get_environ_vars(self, prefix='VIRTUALENV_'):
+            yield ("no_site_packages", "1")
+
+    cop = MyConfigOptionParser()
+    cop.add_option(
+        '--no-site-packages',
+        dest='system_site_packages',
+        action='store_false',
+        help="Don't give access to the global site-packages dir to the "
+             "virtual environment (default)")
+
+    defaults = {}
+    cop.update_defaults(defaults)
+    assert defaults == {'system_site_packages': 0}