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 |
|---|---|---|
| python-virtualenv.changes | 0000039183 38.3 KB | |
| python-virtualenv.spec | 0000004453 4.35 KB | |
| virtualenv-20.7.0.tar.gz | 0008714219 8.31 MB |
Revision 44 (latest revision is 66)
Dominique Leuenberger (dimstar_suse)
accepted
request 918847
from
Steve Kowalik (StevenK)
(revision 44)
- Add missing Requires on two modules.
- Drop no longer required appdirs Requires.
- Shift new BuildRequires to :test to avoid cycles.
- Switch off tests, they are just broken.
- Update to 20.7.0:
- Removed xonsh activator due to this breaking fairly often the
CI and lack of support from those packages maintainers,
upstream is encouraged to continue supporting the project as
a plugin
- Support Python interpreters without distutils (fallback to
syconfig in these cases)
- Plugins now use 'selectable' entry points
- add libffi-7.dll to the hard-coded list of dlls for PyPy
- Drop python 3.4 support as it has been over 2 years since EOL
- Use the better maintained platformdirs instead of appdirs
- Built in discovery class is always preferred over plugin
supplied classes.
- On the programmatic API allow passing in the environment
variable dictionary to use, defaults to os.environ if not
specified
- The builtin discovery takes now a --try-first-with argument
and is first attempted as valid interpreters. One can use
this to force discovery of a given python executable when the
discovery order/mechanism raises errors
Comments 0