mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
Fix merge bustage.
This commit is contained in:
David Anderson
parent
c0d2427d66
commit
bc48a00e07
@ -1,7 +1,7 @@
|
||||
<html>
|
||||
<!-- https://bugzilla.mozilla.org/show_bug.cgi?id=495388 -->
|
||||
<head>
|
||||
<title>test nsHTMLTableAccessible::IsProbablyForLayout implementation</title>
|
||||
<title>test HTMLTableAccessible::IsProbablyForLayout implementation</title>
|
||||
<link rel="stylesheet" type="text/css"
|
||||
href="chrome://mochikit/content/tests/SimpleTest/test.css" />
|
||||
|
||||
|
||||
@ -1,65 +0,0 @@
|
||||
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
||||
/* This Source Code Form is subject to the terms of the Mozilla Public
|
||||
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
||||
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
||||
|
||||
/*
|
||||
|
||||
Private interface to the XBL service
|
||||
|
||||
*/
|
||||
|
||||
#ifndef nsIXBLService_h__
|
||||
#define nsIXBLService_h__
|
||||
|
||||
#include "nsISupports.h"
|
||||
|
||||
class nsIContent;
|
||||
class nsIDocument;
|
||||
class nsIDOMEventTarget;
|
||||
class nsIDOMNodeList;
|
||||
class nsXBLBinding;
|
||||
class nsXBLDocumentInfo;
|
||||
class nsIURI;
|
||||
class nsIAtom;
|
||||
class nsIPrincipal;
|
||||
|
||||
#define NS_IXBLSERVICE_IID \
|
||||
{ 0x8a25483c, 0x1ac6, 0x4796, { 0xa6, 0x12, 0x5a, 0xe0, 0x5c, 0x83, 0x65, 0x0b } }
|
||||
|
||||
class nsIXBLService : public nsISupports
|
||||
{
|
||||
public:
|
||||
NS_DECLARE_STATIC_IID_ACCESSOR(NS_IXBLSERVICE_IID)
|
||||
|
||||
// This function loads a particular XBL file and installs all of the bindings
|
||||
// onto the element. aOriginPrincipal must not be null here.
|
||||
NS_IMETHOD LoadBindings(nsIContent* aContent, nsIURI* aURL,
|
||||
nsIPrincipal* aOriginPrincipal, bool aAugmentFlag,
|
||||
nsXBLBinding** aBinding, bool* aResolveStyle) = 0;
|
||||
|
||||
// Indicates whether or not a binding is fully loaded.
|
||||
NS_IMETHOD BindingReady(nsIContent* aBoundElement, nsIURI* aURI, bool* aIsReady) = 0;
|
||||
|
||||
// Retrieves our base class (e.g., tells us what type of frame and content node to build)
|
||||
NS_IMETHOD ResolveTag(nsIContent* aContent, PRInt32* aNameSpaceID, nsIAtom** aResult) = 0;
|
||||
|
||||
// This method checks the hashtable and then calls FetchBindingDocument on a
|
||||
// miss. aOriginPrincipal or aBoundDocument may be null to bypass security
|
||||
// checks.
|
||||
NS_IMETHOD LoadBindingDocumentInfo(nsIContent* aBoundElement,
|
||||
nsIDocument* aBoundDocument,
|
||||
nsIURI* aBindingURI,
|
||||
nsIPrincipal* aOriginPrincipal,
|
||||
bool aForceSyncLoad,
|
||||
nsXBLDocumentInfo** aResult) = 0;
|
||||
|
||||
// Hooks up the global key event handlers to the document root.
|
||||
NS_IMETHOD AttachGlobalKeyHandler(nsIDOMEventTarget* aTarget) = 0;
|
||||
NS_IMETHOD DetachGlobalKeyHandler(nsIDOMEventTarget* aTarget) = 0;
|
||||
|
||||
};
|
||||
|
||||
NS_DEFINE_STATIC_IID_ACCESSOR(nsIXBLService, NS_IXBLSERVICE_IID)
|
||||
|
||||
#endif // nsIXBLService_h__
|
||||
@ -1,4 +1,4 @@
|
||||
50// -*- Mode: js2; tab-width: 2; indent-tabs-mode: nil; js2-basic-offset: 2; js2-skip-preprocessor-directives: t; -*-
|
||||
// -*- Mode: js2; tab-width: 2; indent-tabs-mode: nil; js2-basic-offset: 2; js2-skip-preprocessor-directives: t; -*-
|
||||
/* This Source Code Form is subject to the terms of the Mozilla Public
|
||||
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
||||
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
||||
|
||||
@ -668,7 +668,6 @@ pref("javascript.options.strict.debug", true);
|
||||
#endif
|
||||
pref("javascript.options.relimit", true);
|
||||
pref("javascript.options.methodjit.content", true);
|
||||
pref("javascript.options.ion.content", true);
|
||||
pref("javascript.options.methodjit.chrome", true);
|
||||
pref("javascript.options.pccounts.content", false);
|
||||
pref("javascript.options.pccounts.chrome", false);
|
||||
|
||||
@ -1,335 +0,0 @@
|
||||
virtualenv
|
||||
==========
|
||||
|
||||
* `Discussion list <http://groups.google.com/group/python-virtualenv/>`_
|
||||
* `Bugs <https://bitbucket.org/ianb/virtualenv/issues/>`_
|
||||
|
||||
.. contents::
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
news
|
||||
license
|
||||
|
||||
.. comment: split here
|
||||
|
||||
Status and License
|
||||
------------------
|
||||
|
||||
``virtualenv`` is a successor to `workingenv
|
||||
<http://cheeseshop.python.org/pypi/workingenv.py>`_, and an extension
|
||||
of `virtual-python
|
||||
<http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-python>`_.
|
||||
|
||||
It is written by Ian Bicking, and sponsored by the `Open Planning
|
||||
Project <http://openplans.org>`_. It is licensed under an
|
||||
`MIT-style permissive license <license.html>`_.
|
||||
|
||||
You can install it with ``easy_install virtualenv``, or from the `hg
|
||||
repository <http://bitbucket.org/ianb/virtualenv>`_ or from a `tarball
|
||||
<http://bitbucket.org/ianb/virtualenv/get/tip.gz#egg=virtualenv-tip>`_
|
||||
``easy_install virtualenv==tip``.
|
||||
|
||||
What It Does
|
||||
------------
|
||||
|
||||
``virtualenv`` is a tool to create isolated Python environments.
|
||||
|
||||
The basic problem being addressed is one of dependencies and versions,
|
||||
and indirectly permissions. Imagine you have an application that
|
||||
needs version 1 of LibFoo, but another application requires version
|
||||
2. How can you use both these applications? If you install
|
||||
everything into ``/usr/lib/python2.4/site-packages`` (or whatever your
|
||||
platform's standard location is), it's easy to end up in a situation
|
||||
where you unintentionally upgrade an application that shouldn't be
|
||||
upgraded.
|
||||
|
||||
Or more generally, what if you want to install an application *and
|
||||
leave it be*? If an application works, any change in its libraries or
|
||||
the versions of those libraries can break the application.
|
||||
|
||||
Also, what if you can't install packages into the global
|
||||
``site-packages`` directory? For instance, on a shared host.
|
||||
|
||||
In all these cases, ``virtualenv`` can help you. It creates an
|
||||
environment that has its own installation directories, that doesn't
|
||||
share libraries with other virtualenv environments (and optionally
|
||||
doesn't use the globally installed libraries either).
|
||||
|
||||
The basic usage is::
|
||||
|
||||
$ python virtualenv.py ENV
|
||||
|
||||
If you install it you can also just do ``virtualenv ENV``.
|
||||
|
||||
This creates ``ENV/lib/python2.4/site-packages`` (or
|
||||
``ENV/lib/python2.5/site-packages`` on Python 2.5, etc), where any
|
||||
libraries you install will go. It also creates ``ENV/bin/python``,
|
||||
which is a Python interpreter that uses this environment. Anytime you
|
||||
use that interpreter (including when a script has
|
||||
``#!/path/to/ENV/bin/python`` in it) the libraries in that environment
|
||||
will be used. (**Note for Windows:** scripts and executables on
|
||||
Windows go in ``ENV\Scripts\``; everywhere you see ``bin/`` replace it
|
||||
with ``Scripts\``)
|
||||
|
||||
It also installs `Setuptools
|
||||
<http://peak.telecommunity.com/DevCenter/setuptools>`_ for you, and if
|
||||
you use ``ENV/bin/easy_install`` the packages will be installed into
|
||||
the environment.
|
||||
|
||||
If you use the ``--distribute`` option, it will install `distribute
|
||||
<http://pypi.python.org/pypi/distribute>`_ for you, instead of setuptools,
|
||||
and if you use `ENV/bin/easy_install`` the packages will be installed into the
|
||||
environment.
|
||||
|
||||
To use Distribute just call virtualenv like this::
|
||||
|
||||
$ python virtualenv.py --distribute ENV
|
||||
|
||||
You can also set the environment variable VIRTUALENV_USE_DISTRIBUTE (since 1.4.4)
|
||||
and be a good Comrade
|
||||
|
||||
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
|
||||
``virtualenv.create_bootstrap_script(extra_text)``, and write the
|
||||
result to your new bootstrapping script. Here's the documentation
|
||||
from the docstring:
|
||||
|
||||
Creates a bootstrap script, 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:
|
||||
|
||||
``extend_parser(optparse_parser)``:
|
||||
You can add or remove options from the parser here.
|
||||
|
||||
``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]``).
|
||||
|
||||
``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://svn.openplans.org/svn/fassembler/trunk/fassembler/create-venv-script.py>`_.
|
||||
|
||||
activate script
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
In a newly created virtualenv there will be a ``bin/activate`` shell
|
||||
script, or a ``Scripts/activate.bat`` batch file on Windows.
|
||||
|
||||
On Posix systems you can do::
|
||||
|
||||
$ source bin/activate
|
||||
|
||||
This will change your ``$PATH`` to point to the virtualenv ``bin/``
|
||||
directory. Unlike workingenv, this is all it
|
||||
does; it's a convenience. But if you use the complete path like
|
||||
``/path/to/env/bin/python script.py`` you do not need to activate the
|
||||
environment first. You have to use ``source`` because it changes the
|
||||
environment in-place. After activating an environment you can use the
|
||||
function ``deactivate`` to undo the changes.
|
||||
|
||||
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\bin\activate.bat
|
||||
|
||||
And use ``deactivate.bat`` to undo the changes.
|
||||
|
||||
The ``--no-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.
|
||||
|
||||
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,
|
||||
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. Also this does not
|
||||
currently work on Windows.
|
||||
|
||||
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 or distribute
|
||||
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:** 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).
|
||||
|
||||
Currently the ``--no-site-packages`` option will not be honored if you
|
||||
use this on an environment.
|
||||
|
||||
Compare & Contrast with Alternatives
|
||||
------------------------------------
|
||||
|
||||
There are several alternatives that create isolated environments:
|
||||
|
||||
* ``workingenv`` (which I do not suggest you use anymore) is the
|
||||
predecessor to this library. It used the main Python interpreter,
|
||||
but relied on setting ``$PYTHONPATH`` to activate the environment.
|
||||
This causes problems when running Python scripts that aren't part of
|
||||
the environment (e.g., a globally installed ``hg`` or ``bzr``). It
|
||||
also conflicted a lot with Setuptools.
|
||||
|
||||
* `virtual-python
|
||||
<http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-python>`_
|
||||
is also a predecessor to this library. It uses only symlinks, so it
|
||||
couldn't work on Windows. It also symlinks over the *entire*
|
||||
standard library and global ``site-packages``. As a result, it
|
||||
won't see new additions to the global ``site-packages``.
|
||||
|
||||
This script only symlinks a small portion of the standard library
|
||||
into the environment, and so on Windows it is feasible to simply
|
||||
copy these files over. Also, it creates a new/empty
|
||||
``site-packages`` and also adds the global ``site-packages`` to the
|
||||
path, so updates are tracked separately. This script also installs
|
||||
Setuptools automatically, saving a step and avoiding the need for
|
||||
network access.
|
||||
|
||||
* `zc.buildout <http://pypi.python.org/pypi/zc.buildout>`_ doesn't
|
||||
create an isolated Python environment in the same style, but
|
||||
achieves similar results through a declarative config file that sets
|
||||
up scripts with very particular packages. As a declarative system,
|
||||
it is somewhat easier to repeat and manage, but more difficult to
|
||||
experiment with. ``zc.buildout`` includes the ability to setup
|
||||
non-Python systems (e.g., a database server or an Apache instance).
|
||||
|
||||
I *strongly* recommend anyone doing application development or
|
||||
deployment use one of these tools.
|
||||
|
||||
Other Documentation and Links
|
||||
-----------------------------
|
||||
|
||||
* James Gardner has written a tutorial on using `virtualenv with
|
||||
Pylons
|
||||
<http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox>`_.
|
||||
|
||||
* `Blog announcement
|
||||
<http://blog.ianbicking.org/2007/10/10/workingenv-is-dead-long-live-virtualenv/>`_.
|
||||
|
||||
* Doug Hellmann wrote a description of his `command-line work flow
|
||||
using virtualenv (virtualenvwrapper)
|
||||
<http://www.doughellmann.com/articles/CompletelyDifferent-2008-05-virtualenvwrapper/index.html>`_
|
||||
including some handy scripts to make working with multiple
|
||||
environments easier. He also wrote `an example of using virtualenv
|
||||
to try IPython
|
||||
<http://www.doughellmann.com/articles/CompletelyDifferent-2008-02-ipython-and-virtualenv/index.html>`_.
|
||||
|
||||
* Chris Perkins created a `showmedo video including virtualenv
|
||||
<http://showmedo.com/videos/video?name=2910000&fromSeriesID=291>`_.
|
||||
|
||||
* `Using virtualenv with mod_wsgi
|
||||
<http://code.google.com/p/modwsgi/wiki/VirtualEnvironments>`_.
|
||||
|
||||
* `virtualenv commands
|
||||
<http://thisismedium.com/tech/extending-virtualenv/>`_ for some more
|
||||
workflow-related tools around virtualenv.
|
||||
@ -1,23 +0,0 @@
|
||||
License
|
||||
=======
|
||||
|
||||
Copyright (c) 2007 Ian Bicking and Contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
"Software"), to deal in the Software without restriction, including
|
||||
without limitation the rights to use, copy, modify, merge, publish,
|
||||
distribute, sublicense, and/or sell copies of the Software, and to
|
||||
permit persons to whom the Software is furnished to do so, subject to
|
||||
the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be
|
||||
included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
@ -1,284 +0,0 @@
|
||||
Changes & News
|
||||
--------------
|
||||
|
||||
hg tip
|
||||
------
|
||||
|
||||
* Fix for Mac OS X Framework builds that use
|
||||
``--universal-archs=intel``
|
||||
|
||||
1.4.7
|
||||
-----
|
||||
|
||||
* Include pip 0.7
|
||||
|
||||
1.4.6
|
||||
~~~~~
|
||||
|
||||
* Allow ``activate.sh`` to skip updating the prompt (by setting
|
||||
``$VIRTUAL_ENV_DISABLE_PROMPT``).
|
||||
|
||||
1.4.5
|
||||
~~~~~
|
||||
|
||||
* Include pip 0.6.3
|
||||
|
||||
* Fix ``activate.bat`` and ``deactivate.bat`` under Windows when
|
||||
``PATH`` contained a parenthesis
|
||||
|
||||
1.4.4
|
||||
~~~~~
|
||||
|
||||
* Include pip 0.6.2 and Distribute 0.6.10
|
||||
|
||||
* Create the ``virtualenv`` script even when Setuptools isn't
|
||||
installed
|
||||
|
||||
* Fix problem with ``virtualenv --relocate`` when ``bin/`` has
|
||||
subdirectories (e.g., ``bin/.svn/``); from Alan Franzoni.
|
||||
|
||||
* If you set ``$VIRTUALENV_USE_DISTRIBUTE`` then virtualenv will use
|
||||
Distribute by default (so you don't have to remember to use
|
||||
``--distribute``).
|
||||
|
||||
1.4.3
|
||||
~~~~~
|
||||
|
||||
* Include pip 0.6.1
|
||||
|
||||
1.4.2
|
||||
~~~~~
|
||||
|
||||
* Fix pip installation on Windows
|
||||
|
||||
* Fix use of stand-alone ``virtualenv.py`` (and boot scripts)
|
||||
|
||||
* Exclude ~/.local (user site-packages) from environments when using
|
||||
``--no-site-packages``
|
||||
|
||||
1.4.1
|
||||
~~~~~
|
||||
|
||||
* Include pip 0.6
|
||||
|
||||
1.4
|
||||
~~~
|
||||
|
||||
* Updated setuptools to 0.6c11
|
||||
|
||||
* Added the --distribute option
|
||||
|
||||
* Fixed packaging problem of support-files
|
||||
|
||||
1.3.4
|
||||
~~~~~
|
||||
|
||||
* Virtualenv now copies the actual embedded Python binary on
|
||||
Mac OS X to fix a hang on Snow Leopard (10.6).
|
||||
|
||||
* Fail more gracefully on Windows when ``win32api`` is not installed.
|
||||
|
||||
* Fix site-packages taking precedent over Jython's ``__classpath__``
|
||||
and also specially handle the new ``__pyclasspath__`` entry in
|
||||
``sys.path``.
|
||||
|
||||
* Now copies Jython's ``registry`` file to the virtualenv if it exists.
|
||||
|
||||
* Better find libraries when compiling extensions on Windows.
|
||||
|
||||
* Create ``Scripts\pythonw.exe`` on Windows.
|
||||
|
||||
* Added support for the Debian/Ubuntu
|
||||
``/usr/lib/pythonX.Y/dist-packages`` directory.
|
||||
|
||||
* Set ``distutils.sysconfig.get_config_vars()['LIBDIR']`` (based on
|
||||
``sys.real_prefix``) which is reported to help building on Windows.
|
||||
|
||||
* Make ``deactivate`` work on ksh
|
||||
|
||||
* Fixes for ``--python``: make it work with ``--relocatable`` and the
|
||||
symlink created to the exact Python version.
|
||||
|
||||
1.3.3
|
||||
~~~~~
|
||||
|
||||
* Use Windows newlines in ``activate.bat``, which has been reported to help
|
||||
when using non-ASCII directory names.
|
||||
|
||||
* Fixed compatibility with Jython 2.5b1.
|
||||
|
||||
* Added a function ``virtualenv.install_python`` for more fine-grained
|
||||
access to what ``virtualenv.create_environment`` does.
|
||||
|
||||
* Fix `a problem <https://bugs.launchpad.net/virtualenv/+bug/241581>`_
|
||||
with Windows and paths that contain spaces.
|
||||
|
||||
* If ``/path/to/env/.pydistutils.cfg`` exists (or
|
||||
``/path/to/env/pydistutils.cfg`` on Windows systems) then ignore
|
||||
``~/.pydistutils.cfg`` and use that other file instead.
|
||||
|
||||
* Fix ` a problem
|
||||
<https://bugs.launchpad.net/virtualenv/+bug/340050>`_ picking up
|
||||
some ``.so`` libraries in ``/usr/local``.
|
||||
|
||||
1.3.2
|
||||
~~~~~
|
||||
|
||||
* Remove the ``[install] prefix = ...`` setting from the virtualenv
|
||||
``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``
|
||||
and find a pre-downloaded Setuptools egg using that.
|
||||
|
||||
* Added platform-specific paths, like ``/usr/lib/pythonX.Y/plat-linux2``
|
||||
|
||||
1.3.1
|
||||
~~~~~
|
||||
|
||||
* Real Python 2.6 compatibility. Backported the Python 2.6 updates to
|
||||
``site.py``, including `user directories
|
||||
<http://docs.python.org/dev/whatsnew/2.6.html#pep-370-per-user-site-packages-directory>`_
|
||||
(this means older versions of Python will support user directories,
|
||||
whether intended or not).
|
||||
|
||||
* Always set ``[install] prefix`` in ``distutils.cfg`` -- previously
|
||||
on some platforms where a system-wide ``distutils.cfg`` was present
|
||||
with a ``prefix`` setting, packages would be installed globally
|
||||
(usually in ``/usr/local/lib/pythonX.Y/site-packages``).
|
||||
|
||||
* Sometimes Cygwin seems to leave ``.exe`` off ``sys.executable``; a
|
||||
workaround is added.
|
||||
|
||||
* Fix ``--python`` option.
|
||||
|
||||
* Fixed handling of Jython environments that use a
|
||||
jython-complete.jar.
|
||||
|
||||
1.3
|
||||
~~~
|
||||
|
||||
* Update to Setuptools 0.6c9
|
||||
* Added an option ``virtualenv --relocatable EXISTING_ENV``, which
|
||||
will make an existing environment "relocatable" -- the paths will
|
||||
not be absolute in scripts, ``.egg-info`` and ``.pth`` files. This
|
||||
may assist in building environments that can be moved and copied.
|
||||
You have to run this *after* any new packages installed.
|
||||
* Added ``bin/activate_this.py``, a file you can use like
|
||||
``execfile("path_to/activate_this.py",
|
||||
dict(__file__="path_to/activate_this.py"))`` -- this will activate
|
||||
the environment in place, similar to what `the mod_wsgi example
|
||||
does <http://code.google.com/p/modwsgi/wiki/VirtualEnvironments>`_.
|
||||
* For Mac framework builds of Python, the site-packages directory
|
||||
``/Library/Python/X.Y/site-packages`` is added to ``sys.path``, from
|
||||
Andrea Rech.
|
||||
* Some platform-specific modules in Macs are added to the path now
|
||||
(``plat-darwin/``, ``plat-mac/``, ``plat-mac/lib-scriptpackages``),
|
||||
from Andrea Rech.
|
||||
* Fixed a small Bashism in the ``bin/activate`` shell script.
|
||||
* Added ``__future__`` to the list of required modules, for Python
|
||||
2.3. You'll still need to backport your own ``subprocess`` module.
|
||||
* Fixed the ``__classpath__`` entry in Jython's ``sys.path`` taking
|
||||
precedent over virtualenv's libs.
|
||||
|
||||
1.2
|
||||
~~~
|
||||
|
||||
* Added a ``--python`` option to select the Python interpreter.
|
||||
* Add ``warnings`` to the modules copied over, for Python 2.6 support.
|
||||
* Add ``sets`` to the module copied over for Python 2.3 (though Python
|
||||
2.3 still probably doesn't work).
|
||||
|
||||
1.1.1
|
||||
~~~~~
|
||||
|
||||
* Added support for Jython 2.5.
|
||||
|
||||
1.1
|
||||
~~~
|
||||
|
||||
* Added support for Python 2.6.
|
||||
* Fix a problem with missing ``DLLs/zlib.pyd`` on Windows. Create
|
||||
* ``bin/python`` (or ``bin/python.exe``) even when you run virtualenv
|
||||
with an interpreter named, e.g., ``python2.4``
|
||||
* Fix MacPorts Python
|
||||
* Added --unzip-setuptools option
|
||||
* Update to Setuptools 0.6c8
|
||||
* If the current directory is not writable, run ez_setup.py in ``/tmp``
|
||||
* Copy or symlink over the ``include`` directory so that packages will
|
||||
more consistently compile.
|
||||
|
||||
1.0
|
||||
~~~
|
||||
|
||||
* Fix build on systems that use ``/usr/lib64``, distinct from
|
||||
``/usr/lib`` (specifically CentOS x64).
|
||||
* Fixed bug in ``--clear``.
|
||||
* Fixed typos in ``deactivate.bat``.
|
||||
* Preserve ``$PYTHONPATH`` when calling subprocesses.
|
||||
|
||||
0.9.2
|
||||
~~~~~
|
||||
|
||||
* Fix include dir copying on Windows (makes compiling possible).
|
||||
* Include the main ``lib-tk`` in the path.
|
||||
* Patch ``distutils.sysconfig``: ``get_python_inc`` and
|
||||
``get_python_lib`` to point to the global locations.
|
||||
* Install ``distutils.cfg`` before Setuptools, so that system
|
||||
customizations of ``distutils.cfg`` won't effect the installation.
|
||||
* Add ``bin/pythonX.Y`` to the virtualenv (in addition to
|
||||
``bin/python``).
|
||||
* Fixed an issue with Mac Framework Python builds, and absolute paths
|
||||
(from Ronald Oussoren).
|
||||
|
||||
0.9.1
|
||||
~~~~~
|
||||
|
||||
* Improve ability to create a virtualenv from inside a virtualenv.
|
||||
* Fix a little bug in ``bin/activate``.
|
||||
* Actually get ``distutils.cfg`` to work reliably.
|
||||
|
||||
0.9
|
||||
~~~
|
||||
|
||||
* Added ``lib-dynload`` and ``config`` to things that need to be
|
||||
copied over in an environment.
|
||||
* Copy over or symlink the ``include`` directory, so that you can
|
||||
build packages that need the C headers.
|
||||
* Include a ``distutils`` package, so you can locally update
|
||||
``distutils.cfg`` (in ``lib/pythonX.Y/distutils/distutils.cfg``).
|
||||
* Better avoid downloading Setuptools, and hitting PyPI on environment
|
||||
creation.
|
||||
* Fix a problem creating a ``lib64/`` directory.
|
||||
* Should work on MacOSX Framework builds (the default Python
|
||||
installations on Mac). Thanks to Ronald Oussoren.
|
||||
|
||||
0.8.4
|
||||
~~~~~
|
||||
|
||||
* Windows installs would sometimes give errors about ``sys.prefix`` that
|
||||
were inaccurate.
|
||||
* Slightly prettier output.
|
||||
|
||||
0.8.3
|
||||
~~~~~
|
||||
|
||||
* Added support for Windows.
|
||||
|
||||
0.8.2
|
||||
~~~~~
|
||||
|
||||
* Give a better warning if you are on an unsupported platform (Mac
|
||||
Framework Pythons, and Windows).
|
||||
* Give error about running while inside a workingenv.
|
||||
* Give better error message about Python 2.3.
|
||||
|
||||
0.8.1
|
||||
~~~~~
|
||||
|
||||
Fixed packaging of the library.
|
||||
|
||||
0.8
|
||||
~~~
|
||||
|
||||
Initial release. Everything is changed and new!
|
||||
@ -1,23 +0,0 @@
|
||||
License
|
||||
=======
|
||||
|
||||
Copyright (c) 2007 Ian Bicking and Contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
"Software"), to deal in the Software without restriction, including
|
||||
without limitation the rights to use, copy, modify, merge, publish,
|
||||
distribute, sublicense, and/or sell copies of the Software, and to
|
||||
permit persons to whom the Software is furnished to do so, subject to
|
||||
the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be
|
||||
included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
Binary file not shown.
Binary file not shown.
Loading…
Reference in New Issue
Block a user