Skip to content

invert site-packages behavior #178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 28, 2011
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions docs/index.txt
Original file line number Diff line number Diff line change
Expand Up @@ -207,15 +207,16 @@ On Windows you just do::

And use ``deactivate.bat`` to undo the changes.

The ``--no-site-packages`` Option
The ``--use-site-packages`` Option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you build with ``virtualenv --no-site-packages ENV`` it will *not*
inherit any packages from ``/usr/lib/python2.5/site-packages`` (or
wherever your global site-packages directory is). This can be used if
you don't have control over site-packages and don't want to depend on
the packages there, or you just want more isolation from the global
system.
If you build with ``virtualenv --use-site-packages ENV``, your virtual
environment will inherit packages from ``/usr/lib/python2.5/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``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand All @@ -236,8 +237,7 @@ can setup the environment like::
This will change ``sys.path`` and even change ``sys.prefix``, but also allow
you to use an existing interpreter. Items in your environment will show up
first on ``sys.path``, before global items. However, global items will
always be accessible -- this technique does not support the
``--no-site-packages`` flag. Also, this cannot undo the activation of other
always be accessible. Also, this cannot undo the activation of other
environments, or modules that have been imported. You shouldn't try to, for
instance, activate an environment before a web request; you should activate
*one* environment as early as possible, and not do it again in that process.
Expand Down Expand Up @@ -277,8 +277,8 @@ libraries on the system, if those C libraries are located somewhere
different (either different versions, or a different filesystem
layout).

Currently the ``--no-site-packages`` option will not be honored if you
use this on an environment.
If you use this flag to create an environment, currently, the
``--use-site-packages`` option will be implied.

The ``--extra-search-dir`` Option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down
10 changes: 10 additions & 0 deletions docs/news.txt
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,16 @@ Next release (1.7) schedule

Beta release mid-July 2011, final release early August.

Next release
~~~~~~~~~~~~

* Made ``--no-site-packages`` behavior the default behavior. The
``--no-site-packages`` flag is still permitted, but displays a warning when
used.

* New flag: ``--use-site-packages``; this flag should be passed to get the
previous default global-site-package-including behavior back.

1.6.4 (2011-07-21)
~~~~~~~~~~~~~~~~~~

Expand Down
23 changes: 18 additions & 5 deletions virtualenv.py
Original file line number Diff line number Diff line change
Expand Up @@ -494,7 +494,7 @@ def _install_req(py_executable, unzip=False, distribute=False,
if not hasattr(pkg_resources, '_distribute'):
location = os.path.dirname(pkg_resources.__file__)
logger.notify("A globally installed setuptools was found (in %s)" % location)
logger.notify("Use the --no-site-packages option to use distribute in "
logger.notify("Refrain from using the --use-site-packages option to use distribute in "
"the virtualenv.")
except ImportError:
pass
Expand Down Expand Up @@ -709,6 +709,13 @@ def main():
help="Don't give access to the global site-packages dir to the "
"virtual environment")

parser.add_option(
'--use-site-packages',
dest='use_site_packages',
action='store_true',
help="Give access to the global site-packages dir to the "
"virtual environment")

parser.add_option(
'--unzip-setuptools',
dest='unzip_setuptools',
Expand Down Expand Up @@ -802,7 +809,13 @@ def main():
make_environment_relocatable(home_dir)
return

create_environment(home_dir, site_packages=not options.no_site_packages, clear=options.clear,
if options.no_site_packages:
logger.warn('The --no-site-packages flag is deprecated; it is now '
'the default behavior.')

create_environment(home_dir,
site_packages=options.use_site_packages,
clear=options.clear,
unzip_setuptools=options.unzip_setuptools,
use_distribute=options.use_distribute or majver > 2,
prompt=options.prompt,
Expand Down Expand Up @@ -882,14 +895,14 @@ def call_subprocess(cmd, show_stdout=True,
% (cmd_desc, proc.returncode))


def create_environment(home_dir, site_packages=True, clear=False,
def create_environment(home_dir, site_packages=False, clear=False,
unzip_setuptools=False, use_distribute=False,
prompt=None, search_dirs=None, never_download=False):
"""
Creates a new environment in ``home_dir``.

If ``site_packages`` is true (the default) then the global
``site-packages/`` directory will be on the path.
If ``site_packages`` is true, then the global ``site-packages/``
directory will be on the path.

If ``clear`` is true (default False) then the environment will
first be cleared.
Expand Down