Virtual Python Environment builder
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 platforms standard location
is), its easy to end up in a situation where you unintentionally upgrade an
application that shouldnt 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 cant 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 doesnt share libraries with other
virtualenv environments (and optionally doesnt use the globally installed
libraries either).
- Developed at devel:languages:python
- Sources inherited from project openSUSE:Factory
-
10
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout home:seife:Factory/python-virtualenv && cd $_ - Create Badge
Source Files
| Filename | Size | Changed |
|---|---|---|
| _multibuild | 0000000053 53 Bytes | |
| python-virtualenv.changes | 0000027283 26.6 KB | |
| python-virtualenv.spec | 0000003951 3.86 KB | |
| virtualenv-16.7.5.tar.gz | 0005111957 4.88 MB |
Revision 35 (latest revision is 66)
Dominique Leuenberger (dimstar_suse)
accepted
request 731579
from
Tomáš Chvátal (scarabeus_iv)
(revision 35)
- Use multibuild to avoid cycles with pytest - Update to 16.7.5: * fix powershell activation when sourced (#1398) * fix regression - sh activation script not working under sh (only bash) (#1396) * activate.ps1 syntax and style updated to follow PSStyleAnalyzer rules (#1371) * Allow creating virtual environments for 3.xy. (#1385) * Report error when running activate scripts directly * Extend the LICENSE search paths list by lib64/pythonX.Y to support Linux vendors who install their Python to /usr/lib64/pythonX.Y * Raise an error if the target path contains the operating systems path separator (using this would break our activation scripts) * Drop Jython support * Add tests covering prompt manipulation during activation/deactivation, and harmonize behavior of all supported shells - Update to 16.4.3: * Revert the symlink fix, causing debian packaging issues. (#1390) * Fix license() builtin by copying the LICENSE file into the virtualenv - by asottile. (#1317) * fixes the scenario where the python base install is symlinked with relative symlinks (#490) * Use importlib over imp in virtualenv.py for python >= 3.4 - by Anthony Sottile (#1293) * Copy or link PyPy header files instead of include directory itself (#1302) * Allow virtualenv creation with older pip not having config command correspondingly disabling configuration related features (such as pip cert setting) in this case. (#1303) * Use importlib over deprecated imp` in ``distutils/__init__.py for python 3 - by Anthony Sottile (#955) * Preserve cert option defined in pip.conf or environment variable. (#1273) * fixed a ResourceWarning: unclosed file in call_subprocess() - by Mickaël Schoentgen (#1277) * pre-import some built-in modules in site.py on PyPy according to PyPy's site.py - by microdog (#1281) * Copy files from sys.exec_prefix only if it is really different path than used prefix, bugfix for #1270 (#1282) * copyfile handles relative symlinks and symlinks to symlinks, avoiding problems when Python was installed using stow or homebrew. (#268) * Fix preserving of original path when using fish and a subshell. (#904) * Drop the source layout of the project, going back to how the source was laid out before 16.1.0. (#1241) * Fix bootstrap script generation broken with 16.0.0. Support now both CPython, pypy, jython. (#1244) * lib64 symlink is again relative (as was with < 16.1.0). (#1248)
Comments 0