RubyGems - libv8 - Versions diffs - 4.5.95.5 → 5.0.71.48.0beta2 - Mend

libv8 4.5.95.5 → 5.0.71.48.0beta2

Files changed (332) hide show

data/vendor/depot_tools/bootstrap/virtualenv/docs/reference.rst DELETED

@@ -1,256 +0,0 @@
-Reference Guide
-===============
-``virtualenv`` Command
-----------------------
-.. _usage:
-Usage
-~~~~~
-:command:`virtualenv [OPTIONS] ENV_DIR`
-    Where ``ENV_DIR`` is an absolute or relative path to a directory to create
-    the virtual environment in.
-.. _options:
-Options
-~~~~~~~
-.. program: virtualenv
-.. option:: --version
-   show program's version number and exit
-.. option:: -h, --help
-   show this help message and exit
-.. option:: -v, --verbose
-   Increase verbosity.
-.. option:: -q, --quiet
-   Decrease verbosity.
-.. option:: -p PYTHON_EXE, --python=PYTHON_EXE
-   The Python interpreter to use, e.g.,
-   --python=python2.5 will use the python2.5 interpreter
-   to create the new environment.  The default is the
-   interpreter that virtualenv was installed with
-   (like ``/usr/bin/python``)
-.. option:: --clear
-   Clear out the non-root install and start from scratch.
-.. option:: --system-site-packages
-   Give the virtual environment access to the global
-   site-packages.
-.. option:: --always-copy
-   Always copy files rather than symlinking.
-.. option:: --relocatable
-   Make an EXISTING virtualenv environment relocatable.
-   This fixes up scripts and makes all .pth files relative.
-.. option:: --unzip-setuptools
-   Unzip Setuptools when installing it.
-.. option:: --no-setuptools
-   Do not install setuptools (or pip) in the new
-   virtualenv.
-.. option:: --no-pip
-   Do not install pip in the new virtualenv.
-.. option:: --extra-search-dir=DIR
-   Directory to look for setuptools/pip distributions in.
-   This option can be specified multiple times.
-.. option:: --prompt=PROMPT
-   Provides an alternative prompt prefix for this
-   environment.
-.. option:: --never-download
-   DEPRECATED. Retained only for backward compatibility.
-   This option has no effect. Virtualenv never downloads
-   pip or setuptools.
-.. option:: --no-site-packages
-   DEPRECATED. Retained only for backward compatibility.
-   Not having access to global site-packages is now the
-   default behavior.
-.. option:: --distribute
-.. option:: --setuptools
-   Legacy; now have no effect.  Before version 1.10 these could be used
-   to choose whether to install Distribute_ or Setuptools_ into the created
-   virtualenv. Distribute has now been merged into Setuptools, and the
-   latter is always installed.
-.. _Distribute: https://pypi.python.org/pypi/distribute
-.. _Setuptools: https://pypi.python.org/pypi/setuptools
-Configuration
--------------
-Environment Variables
-~~~~~~~~~~~~~~~~~~~~~
-Each command line option is automatically used to look for environment
-variables with the name format ``VIRTUALENV_<UPPER_NAME>``. That means
-the name of the command line options are capitalized and have dashes
-(``'-'``) replaced with underscores (``'_'``).
-For example, to automatically use a custom Python binary instead of the
-one virtualenv is run with you can also set an environment variable::
-  $ export VIRTUALENV_PYTHON=/opt/python-3.3/bin/python
-  $ virtualenv ENV
-It's the same as passing the option to virtualenv directly::
-  $ virtualenv --python=/opt/python-3.3/bin/python ENV
-This also works for appending command line options, like ``--find-links``.
-Just leave an empty space between the passed values, e.g.::
-  $ export VIRTUALENV_EXTRA_SEARCH_DIR="/path/to/dists /path/to/other/dists"
-  $ virtualenv ENV
-is the same as calling::
-  $ virtualenv --extra-search-dir=/path/to/dists --extra-search-dir=/path/to/other/dists ENV
-.. envvar:: VIRTUAL_ENV_DISABLE_PROMPT
-   Any virtualenv created when this is set to a non-empty value will not have
-   it's :ref:`activate` modify the shell prompt.
-Configuration File
-~~~~~~~~~~~~~~~~~~
-virtualenv also looks for a standard ini config file. On Unix and Mac OS X
-that's ``$HOME/.virtualenv/virtualenv.ini`` and on Windows, it's
-``%APPDATA%\virtualenv\virtualenv.ini``.
-The names of the settings are derived from the long command line option,
-e.g. the option :option:`--python <-p>` would look like this::
-  [virtualenv]
-  python = /opt/python-3.3/bin/python
-Appending options like :option:`--extra-search-dir` can be written on multiple
-lines::
-  [virtualenv]
-  extra-search-dir =
-      /path/to/dists
-      /path/to/other/dists
-Please have a look at the output of :option:`--help <-h>` for a full list
-of supported options.
-Extending Virtualenv
---------------------
-Creating Your Own Bootstrap Scripts
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-While this creates an environment, it doesn't put anything into the
-environment. Developers may find it useful to distribute a script
-that sets up a particular environment, for example a script that
-installs a particular web application.
-To create a script like this, call
-:py:func:`virtualenv.create_bootstrap_script`, and write the
-result to your new bootstrapping script.
-.. py:function:: create_bootstrap_script(extra_text)
-   Creates a bootstrap script from ``extra_text``, which is like
-   this script but with extend_parser, adjust_options, and after_install hooks.
-This returns a string that (written to disk of course) can be used
-as a bootstrap script with your own customizations. The script
-will be the standard virtualenv.py script, with your extra text
-added (your extra text should be Python code).
-If you include these functions, they will be called:
-.. py:function:: extend_parser(optparse_parser)
-   You can add or remove options from the parser here.
-.. py:function:: adjust_options(options, args)
-   You can change options here, or change the args (if you accept
-   different kinds of arguments, be sure you modify ``args`` so it is
-   only ``[DEST_DIR]``).
-.. py:function:: after_install(options, home_dir)
-   After everything is installed, this function is called. This
-   is probably the function you are most likely to use. An
-   example would be::
-       def after_install(options, home_dir):
-           if sys.platform == 'win32':
-               bin = 'Scripts'
-           else:
-               bin = 'bin'
-           subprocess.call([join(home_dir, bin, 'easy_install'),
-                            'MyPackage'])
-           subprocess.call([join(home_dir, bin, 'my-package-script'),
-                            'setup', home_dir])
-   This example immediately installs a package, and runs a setup
-   script from that package.
-Bootstrap Example
-~~~~~~~~~~~~~~~~~
-Here's a more concrete example of how you could use this::
-    import virtualenv, textwrap
-    output = virtualenv.create_bootstrap_script(textwrap.dedent("""
-    import os, subprocess
-    def after_install(options, home_dir):
-        etc = join(home_dir, 'etc')
-        if not os.path.exists(etc):
-            os.makedirs(etc)
-        subprocess.call([join(home_dir, 'bin', 'easy_install'),
-                         'BlogApplication'])
-        subprocess.call([join(home_dir, 'bin', 'paster'),
-                         'make-config', 'BlogApplication',
-                         join(etc, 'blog.ini')])
-        subprocess.call([join(home_dir, 'bin', 'paster'),
-                         'setup-app', join(etc, 'blog.ini')])
-    """))
-    f = open('blog-bootstrap.py', 'w').write(output)
-Another example is available `here`__.
-.. __: https://github.com/socialplanning/fassembler/blob/master/fassembler/create-venv-script.py

data/vendor/depot_tools/bootstrap/virtualenv/docs/userguide.rst DELETED

@@ -1,249 +0,0 @@
-User Guide
-==========
-Usage
------
-Virtualenv has one basic command::
-    $ virtualenv ENV
-Where ``ENV`` is a directory to place the new virtual environment. It has
-a number of usual effects (modifiable by many :ref:`options`):
- - :file:`ENV/lib/` and :file:`ENV/include/` are created, containing supporting
-   library files for a new virtualenv python. Packages installed in this
-   environment will live under :file:`ENV/lib/pythonX.X/site-packages/`.
- - :file:`ENV/bin` is created, where executables live - noticeably a new
-   :command:`python`. Thus running a script with ``#! /path/to/ENV/bin/python``
-   would run that script under this virtualenv's python.
- - The crucial packages pip_ and setuptools_ are installed, which allow other
-   packages to be easily installed to the environment. This associated pip
-   can be run from :file:`ENV/bin/pip`.
-The python in your new virtualenv is effectively isolated from the python that
-was used to create it.
-.. _pip: https://pypi.python.org/pypi/pip
-.. _setuptools: https://pypi.python.org/pypi/setuptools
-.. _activate:
-activate script
-~~~~~~~~~~~~~~~
-In a newly created virtualenv there will also be a :command:`activate` shell
-script. For Windows systems, activation scripts are provided for
-the Command Prompt and Powershell.
-On Posix systems, this resides in :file:`/ENV/bin/`, so you can run::
-    $ source bin/activate
-For some shells (e.g. the original Bourne Shell) you may need to use the
-:command:`.` command, when :command:`source` does not exist.
-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.
-The ``activate`` script will also modify your shell prompt to indicate
-which environment is currently active. To disable this behaviour, see
-:envvar:`VIRTUAL_ENV_DISABLE_PROMPT`.
-To undo these changes to your path (and prompt), just run::
-    $ deactivate
-On Windows, the equivalent `activate` script is in the ``Scripts`` folder::
-    > \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 can 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 :option:`--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.
-Windows Notes
-~~~~~~~~~~~~~
-Some paths within the virtualenv are slightly different on Windows: scripts and
-executables on Windows go in ``ENV\Scripts\`` instead of ``ENV/bin/`` and
-libraries go in ``ENV\Lib\`` rather than ``ENV/lib/``.
-To create a virtualenv under a path with spaces in it on Windows, you'll need
-the `win32api <http://sourceforge.net/projects/pywin32/>`_ library installed.
-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
-<http://www.modpython.org/>`_ or `mod_wsgi <http://www.modwsgi.org/>`_
-environment, there is only one interpreter.
-Luckily, it's easy. You must use the custom Python interpreter to
-*install* libraries. But to *use* libraries, you just have to be sure
-the path is correct. A script is available to correct the path. You
-can setup the environment like::
-    activate_this = '/path/to/env/bin/activate_this.py'
-    execfile(activate_this, dict(__file__=activate_this))
-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 (as if the :option:`--system-site-packages` flag had been
-used in creating the environment, whether it was or not). 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.
-Making Environments Relocatable
--------------------------------
-**Note:** this option is somewhat experimental, and there are probably
-caveats that have not yet been identified.
-.. warning::
-    The ``--relocatable`` option currently has a number of issues,
-    and is not guaranteed to work in all circumstances. It is possible
-    that the option will be deprecated in a future version of ``virtualenv``.
-Normally environments are tied to a specific path. That means that
-you cannot move an environment around or copy it to another computer.
-You can fix up an environment to make it relocatable with the
-command::
-    $ virtualenv --relocatable ENV
-This will make some of the files created by setuptools use relative paths,
-and will change all the scripts to use ``activate_this.py`` instead of using
-the location of the Python interpreter to select the environment.
-**Note:** scripts which have been made relocatable will only work if
-the virtualenv is activated, specifically the python executable from
-the virtualenv must be the first one on the system PATH. Also note that
-the activate scripts are not currently made relocatable by
-``virtualenv --relocatable``.
-**Note:** you must run this after you've installed *any* packages into
-the environment. If you make an environment relocatable, then
-install a new package, you must run ``virtualenv --relocatable``
-again.
-Also, this **does not make your packages cross-platform**. You can
-move the directory around, but it can only be used on other similar
-computers. Some known environmental differences that can cause
-incompatibilities: a different version of Python, when one platform
-uses UCS2 for its internal unicode representation and another uses
-UCS4 (a compile-time option), obvious platform changes like Windows
-vs. Linux, or Intel vs. ARM, and if you have libraries that bind to C
-libraries on the system, if those C libraries are located somewhere
-different (either different versions, or a different filesystem
-layout).
-If you use this flag to create an environment, currently, the
-:option:`--system-site-packages` option will be implied.
-The :option:`--extra-search-dir` option
----------------------------------------
-This option allows you to provide your own versions of setuptools and/or
-pip to use instead of the embedded versions that come with virtualenv.
-To use this feature, pass one or more ``--extra-search-dir`` options to
-virtualenv like this::
-    $ virtualenv --extra-search-dir=/path/to/distributions ENV
-The ``/path/to/distributions`` path should point to a directory that contains
-setuptools and/or pip wheels.
-virtualenv will look for wheels in the specified directories, but will use
-pip's standard algorithm for selecting the wheel to install, which looks for
-the latest compatible wheel.
-As well as the extra directories, the search order includes:
-#. The ``virtualenv_support`` directory relative to virtualenv.py
-#. The directory where virtualenv.py is located.
-#. The current directory.
-If no satisfactory local distributions are found, virtualenv will
-fail. Virtualenv will never download packages.