Virtual Python Environment builder
Home Page: https://virtualenv.pypa.io
License: MIT License
A tool for creating isolated virtual python environments.
Everyone interacting in the virtualenv project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the PSF Code of Conduct.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![pre-commit-ci[bot] avatar](https://avatars.githubusercontent.com/in/68672?v=4 "pre-commit-ci[bot]")
The list of directories file_search_dirs returns includes ./virtualenv_support, and pip_install tries to call os.listdir() on each entry in that list. If ./virtualenv_support does not exist, that fails with OSError. This prevents virtualenv from being used as a standalone script, or as a custom bootstrap, unless a virtualenv_support directory is carried along with it.
Fixed in my branch: http://bitbucket.org/carljm/virtualenv/changeset/cc32cbc4b10c/
1.4.9 on Linux.
Traceback (most recent call last):
File "virtualenv.py", line 1645, in <module>
main()
File "virtualenv.py", line 556, in main
prompt=options.prompt)
File "virtualenv.py", line 645, in create_environment
site_packages=site_packages, clear=clear))
File "virtualenv.py", line 769, in install_python
copy_required_modules(home_dir)
File "virtualenv.py", line 723, in copy_required_modules
dst_filename = change_prefix(filename, dst_prefix)
File "virtualenv.py", line 708, in change_prefix
(filename, prefixes)
AssertionError: Filename /home/apy/.local/lib/python2.6/site-packages/readline.so does not start with any of these prefixes: ['/opt/ActivePython-2.6']
pip gets installed with easy_install at the end of the virtualenv call. It uses easy_install pip when using the single-script version of virtualenv.py (i.e. no virtualenv_support), but that does nothing if it already finds an installed version of pip.
Solution: add --upgrade to the easy_install call https://bitbucket.org/ianb/virtualenv/src/204f249efc32/virtualenv.py#cl-405
This is just a copy of pypy issue 604: http://codespeak.net/issue/pypy-dev/issue604
"virtualenv -p pypy --distribute" fails on Mac OS X
I have fixed the bug in my virtualenv-pypy fork on bitbucket, feel free to merge it upstream.
Using Ubuntu 10.04, --relocatable works if I directly invoke the python binary or the setuptools-generated scripts. However, bin/activate still reflects the old path:
> pwd
/home/jhammel
> virtualenv.py foo
New python executable in foo/bin/python
Installing setuptools............done.
> virtualenv.py --relocatable foo
Making script foo/bin/easy_install relative
Making script foo/bin/easy_install-2.6 relative
Making script foo/bin/pip relative
> mv foo bar
> cd bar
> . bin/activate
(foo)> echo $VIRTUAL_ENV
/home/jhammel/foo
(foo)> which python
/usr/bin/python
(foo)>
This is because VIRTUAL_ENV is set to an absolute path in the script. Instead, this should be made relative when --relocatable is called.
Since the activate script must be sourced, it is a bit more complicated to get the path than just (e.g.) dirname $0. The following seems to work in bash:
command=$(history 1) # this should go at the top of the file
parent_path() {
DIRECTORY=$(dirname ${!#})
cd $DIRECTORY/..
pwd
}
VIRTUAL_ENV=$(parent_path $command)
If this meets with your approval, Ian, I'm glad to write a patch.
In a virtualenv with --no-site-packages, I would expect to also be isolated from packages in my ~/.local directory, but I am not.
Also, .local appears in sys.path before the virtualenv site-packages, so it is not possible to even mask packages in .local with packages in the virtualenv without sys.path hacking.
This happens with Python 3.2b2 on OSX:
Create a virtualenv (--no-site-packages)
In the virtualenv interpreter shell, run:
Python 3.2b2 (r32b2:87398, Dec 20 2010, 12:22:28)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
import sysconfig; sysconfig.get_paths('purelib')
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 332, in _init_posix
_parse_makefile(makefile, vars)
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: '/tmp/e/lib/python3.2/config-3.2m/Makefile'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 442, in get_paths
return _expand_vars(scheme, vars)
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 168, in _expand_vars
_extend_dict(vars, get_config_vars())
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 487, in get_config_vars
_init_posix(_CONFIG_VARS)
File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 337, in _init_posix
raise IOError(msg)
IOError: invalid Python installation: unable to open /tmp/e/lib/python3.2/config-3.2m/Makefile (No such file or directory)
1.4.5 comes with Distribute 0.6.8, not 0.6.10 as the release notes claim: http://virtualenv.openplans.org/news.html
https://bitbucket.org/ianb/virtualenv/src/tip/virtualenv_support/distribute-0.6.8.tar.gz (where is the 0.6.10 tarball?)
When running activate.bat or deactivate.bat I always get an error message stating
\ActiveState was unexpected at this time.}}}.
{{{\ActiveState was unexpected at this time.
My PATH begins with C:\Program Files (x86)\ActiveState Komodo IDE 5\. A little bit of googling revealed that others have the same problem. I could not find a reason for this as the if defined _OLD_VIRTUAL_PATH should not evaluate the variable (or have any problem with it if it did).
The attached file fixes this. I have to admit that I don't know //why// this works exactly. It removes the parentheses after the IF statement and puts everything on a single line. It would probably be best if this was tested on other Windows machines.
In addition I removed an unnecessary slash.
On a 64-bit windows deactivate.bat fails with the following message:
\xxxxx was unexpected at this time
where xxxxx is a subfolder in the "%systemdrive%\Program Files (x86)" folder.
activate.bat will also fail if run a second time in a row.
A precondition to this failure is an application installed in the "%systemdrive%\Program Files (x86)" folder, which is added to the path.
Consider the following piece of a batch file:
if defined path (
echo %path%
)
cmd.exe will expand the %path% variable, then find the closing parenthesis within and consider it the end of if-defined operator.
Then it will complain about the remaining part and exit.
Don't use the above mentioned form of if operator with parentheses. For example, the following files work fine:
=================>> deactivate.bat
@echo off
if not defined _OLD_VIRTUAL_PROMPT goto NOVPROMPT
set PROMPT=%_OLD_VIRTUAL_PROMPT%
set _OLD_VIRTUAL_PROMPT=
:NOVPROMPT
if not defined _OLD_VIRTUAL_PATH goto END
set PATH=%_OLD_VIRTUAL_PATH%
set _OLD_VIRTUAL_PATH=
:END
================>> activate.bat
@echo off
set VIRTUAL_ENV=c:\virtualenv\aaaaa
if not defined PROMPT (
set PROMPT=$P$G
)
if not defined _OLD_VIRTUAL_PROMPT goto NOVPROMPT
set PROMPT=%_OLD_VIRTUAL_PROMPT%
:NOVPROMPT
set _OLD_VIRTUAL_PROMPT=%PROMPT%
set PROMPT=(aaaaa) %PROMPT%
if not defined _OLD_VIRTUAL_PATH goto NOVPATH
set PATH=%_OLD_VIRTUAL_PATH%
:NOVPATH
set _OLD_VIRTUAL_PATH=%PATH%
set PATH=%VIRTUAL_ENV%\Scripts;%PATH%
After installing nose, 'which nosetests' returns the virtualenv nosetests (properly), but when I run 'nosetests', the system runs /usr/bin/nosetests.
The system keeps running the wrong nosetests until I exit and reenter the virtualenv.
Here are the steps to recreate:
$ mkvirtualenv --no-site-packages test_nose
$ echo "import sys; print sys.executable" > test_foo.py
$ which nosetests
/usr/bin/nosetests
$ nosetests -s
/usr/bin/python
-------------------------------------------------------------
Ran 0 tests in 0.001s
OK
$ pip install nose
$ which nosetests
/home/brian/.virtualenvs/test_nose/bin/nosetests
$ nosetests -s
/usr/bin/python <--- !!!!!!!
-------------------------------------------------------------
Ran 0 tests in 0.001s
OK
Note: I am assuming that looking at sys.executable is a good proxy for which nosetests is being run.
Just a small patch; --relocatable fails with
IOError: [Errno 21] Is a directory: 'pydevenv-26/bin/.svn'
if there are subdirs in the bin directory.
In this specific situation, I'm using svn to keep my virtual environment under version control (I know mercurial would work better and wouldn't trigger the problem, but we're still in a migration phase at work), and this is interacting with --relocatable for such virtual environment.
The attached patch solves the issue; I'm sorry I'm not yet confident enough with bitbucket to send the patch in a better way, but since it's small I think it'll do no harm.
Bye!
The links to the bugtracker on the PyPI page, as well as on the google group page points to the launchpad tracker. They should be updated to point here.
When doing a "virtualenv --python=c:\python25\python.exe", I got this error:
AssertionError: Filename C:\Python25\lib\site-packages\readline.py does not start with any of these prefixes: ['c:\python25']
Changing the case in the command line made it work.
I want to activate virtualenv and execute some application, which is located at the virtualenv's bin directory:
#!python
import os, subprocess
virtual_env = './python'
bin_dir = os.path.join(virtual_env, 'bin')
# `pip` here
assert os.access(os.path.join(bin_dir, 'pip'), os.X_OK)
activate_this = os.path.join(bin_dir, 'activate_this.py')
execfile(activate_this, dict(__file__=activate_this))
subprocess.call(['pip', '--version'])
But I got "OSError: [Errno 2] No such file or directory"
When I add bin directory to the PATH environment variable, then it works.
#!python
virtual_env = './python'
activate_this = os.path.join(virtual_env, 'bin', 'activate_this.py')
execfile(activate_this, dict(__file__=activate_this))
os.environ['PATH'] = os.pathsep.join([
os.path.join(virtual_env, 'bin'),
os.getenv('PATH', '')])
subprocess.call(['pip', '--version'])
This prints "pip 0.8.1 from /tmp/python/lib/python2.6/site-packages/pip-0.8.1-py2.6.egg (python 2.6)"
Why an activate_this.py script doesn't set PATH for me, like any other bin/activate* scripts?
I like the idea of updating the bash prompt to include the name of the current environment when you run an activate script. But I've got my own nice, colorized prompt, so I'd like to customize how the virtualenv environment name gets added to the prompt.
It seems like the easiest solution would be to add a new environment variable — such as VIRTUAL_ENV_DISABLE_PROMPT — and not do the PS2 magic when this variable is set. That way, my existing prompt definition can check for the existence of VIRTUAL_ENV, and include that as necessary.
It says that only PyPy trunk is supported, however since the release of PyPy 1.4 it's supported out of the box.
When you install virtualenv, it also installs its own setup.py, rebuild-script.py and refresh-support-files.py.
This seems to be a bug, as they're not used by virtualenv.py, and rather weirdly gets put in the root of site-packages, alongside virtualenv.py.
Python 2.7 changed site.USER_BASE to ~/Library/Python/2.7 on Mac. This needs to be fixed in virtualenv.
Here is the patch to provide support for Python 2.7alpha.
Please include in next release.
#!diff
--- virtualenv.py 2009-12-03 01:00:33.000000000 +0100
+++ virtualenv.py 2009-12-22 12:34:50.879493222 +0100
@@ -37,7 +37,7 @@
're', 'sre', 'sre_parse', 'sre_constants', 'sre_compile',
'lib-dynload', 'config', 'zlib']
-if sys.version_info[:2] == (2, 6):
+if sys.version_info[:2] >= (2, 6):
REQUIRED_MODULES.extend(['warnings', 'linecache', '_abcoll', 'abc'])
if sys.version_info[:2] <= (2, 3):
REQUIRED_MODULES.extend(['sets', '__future__'])
It would be nice to skip both; instead I ended up with this hack when I wanted a specific version of setuptools in a virtualenv but had distribute installed globablly:
#!/bin/sh
SETUPTOOLS=specific-setuptools-version.egg
/path/to/virtualenv/bin/pip uninstall distribute
/path/to/virtualenv/bin/python -c "import sys,os; sys.path.insert(0,os.path.abspath('$SETUPTOOLS')); from setuptools.command.easy_install import bootstrap; sys.exit(bootstrap())"
What would have been ideal in my situation would have been options to skip installation of setuptools; and an option that took various eggs to pre-install instead?
There's a missing space in the --help docs. Patch attached.
C:\TEMP>\Python25\Scripts\virtualenv.exe --relocatable python
The environment doesn't have a file python\bin\activate_this.py -- please re-run
virtualenv on this environment to update it
Traceback (most recent call last):
File "C:\Python25\Scripts\virtualenv-script.py", line 9, in <module>
load_entry_point('virtualenv==1.4.3', 'console_scripts', 'virtualenv')()
File "c:\python25\lib\site-packages\virtualenv-1.4.3-py2.5.egg\virtualenv.py",
line 523, in main
make_environment_relocatable(home_dir)
File "c:\python25\lib\site-packages\virtualenv-1.4.3-py2.5.egg\virtualenv.py",
line 928, in make_environment_relocatable
fixup_scripts(home_dir)
File "c:\python25\lib\site-packages\virtualenv-1.4.3-py2.5.egg\virtualenv.py",
line 942, in fixup_scripts
for filename in os.listdir(bin_dir):
WindowsError: [Error 3] The system cannot find the path specified: 'python\\bin/
*.*'
when creating environment which uses jython executable not all required files are copied.
$ virtualenv --version
1.4.3
$ jython --version
Jython 2.5.1
$ virtualenv --no-site-packages -p ~/Applications/jython2.5.1/jython env
Running virtualenv with interpreter /home/aljosa/Applications/jython2.5.1/jython
New jython executable in env/bin/jython
Installing setuptools...........................done.
$ ls env/Lib/*.py|wc -l
19
$ ls ~/Applications/jython2.5.1/Lib/*.py| wc -l
189
comment: don't know why but newlines are ignored
==== The problem
When I attempt to use the activate_this.py script to activate an environment on Windows, the script appears to have correctly reworked the python path through sys.path. However, I am unable to import any module installed to the virtualenv's site-packages.
==== The cause
I believe this is because the activate_this.py script assumes the path to the "site-packages" directory is the same on all platforms, but it is not. The location of the site-packages directory in virtualenvs on Windows is different from the location of the same directory on *nix type OSes.
On *nix type platforms, the location of site-packages is a directory on a path that is dependent on the Python version that was used to create the virtualenv.
So assuming the virtualenv was created with Python2.5, the activate_this.py script should use the location:
VIRTUALENV_BASE/lib/python2.5/site-packages/
On the other hand, with virtualenvs on Windows, the site-packages directory is located at:
*VIRTUALENV_BASE\Lib\site-packages*
==== Possible solution
I think this could be resolved with a simple check like:
#!python
if sys.platform == 'win32':
# use windows site-packages path
else:
# use *nix style site-packages path
==== Steps to re-create
Assumptions:
1. Create an isolated virtualenv and install a simple package in it:
#!console
> virtualenv --no-site-packages mytestenv
> mytestenv\Scripts\activate.bat
(mytestenv) > pip install Yolk
(mytestenv) > yolk --list
pip - X.Y.Z - active
setuptools - X.Y.Z - active
yolk - X.Y.Z - active
(mytestenv) > deactivate
>
2. Verify that you can import the module in the python shell when the virtualenv is activated with the batch file.
#!console
> mytestenv\Scripts\activate.bat
(mytestenv) > python
#!python
>>> import yolk
>>>
3. Create a python test script to activate the environment in python and import the "Yolk" module
#!python
import os
# Activate the environment with activate_this.py
here = os.path.abspath(os.path.dirname(__file__))
activate_this = os.path.join(here, 'mytestenv', 'Scripts', 'activate_this.py')
execfile(activate_this, dict(__file__=activate_this))
import yolk
Save the file as smalltest.py and try to run it.
IMPORTANT -- to recreate this issue properly, ensure that your virtualenv has been deactivated prior to running the smalltest.py script.
#!console
> python smalltest.py
Traceback (most recent call last):
...
ImportError: No module named yolk
Observe that the import failed because the virtualenv was not properly activated by executing the activate_this.py script.
Local development environment:
If you are interested in how I discovered this problem, you may refer to :
From https://bugs.launchpad.net/virtualenv/+bug/325642
carljm@bokchoi:~$ python2.6 -m virtualenv tmp
New python executable in tmp/bin/python2.6
Not overwriting existing python script tmp/bin/python (you must use tmp/bin/python2.6)
Installing setuptools.............done.
carljm@bokchoi:~$ python2.6 -m virtualenv --clear tmp
Deleting tree tmp/lib/python2.6
Not deleting tmp/bin
New python executable in tmp/bin/python2.6
Not overwriting existing python script tmp/bin/python (you must use tmp/bin/python2.6)
Installing setuptools............done.
Make virtualenv --distribute install distutils2
The tar file distributed on PyPI does not have a scripts folder in it. This causes issues when you attempt a distutils build.
I was able to fix this by creating a script directory and copying virtualenv.py into it with the name virtualenv.
ryan@rodimus-prime:~$ tar -xzf virtualenv-1.4.5.tar.gz
ryan@rodimus-prime:~$ cd virtualenv-1.4.5/
ryan@rodimus-prime:~/virtualenv-1.4.5$ python setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.6
copying virtualenv.py -> build/lib.linux-x86_64-2.6
creating build/lib.linux-x86_64-2.6/virtualenv_support
copying virtualenv_support/__init__.py -> build/lib.linux-x86_64-2.6/virtualenv_support
copying virtualenv_support/setuptools-0.6c11-py2.6.egg -> build/lib.linux-x86_64-2.6/virtualenv_support
copying virtualenv_support/distribute-0.6.8.tar.gz -> build/lib.linux-x86_64-2.6/virtualenv_support
copying virtualenv_support/pip-0.6.3.tar.gz -> build/lib.linux-x86_64-2.6/virtualenv_support
running build_scripts
creating build/scripts-2.6
error: file '/home/ryan/virtualenv-1.4.5/scripts/virtualenv' does not exist
I'm getting a bunch of errors using the activate script for Fish (many thanks for supporting this minority shell!).
wilfred@Tenor ~/py-envs> . app-engine/bin/activate.fish
fish: Unknown command “tempfile”
/home/wilfred/py-envs/app-engine/bin/activate.fish (line 1): tempfile
^
in command substitution
called on line 46 of file “/home/wilfred/py-envs/app-engine/bin/activate.fish”,
in . (source) call of file “/home/wilfred/py-envs/app-engine/bin/activate.fish”,
called on standard input,
fish: Expected redirection specification, got token of type “$oldpromptfile”
/home/wilfred/py-envs/app-engine/bin/activate.fish (line 49): echo "function _old_fish_prompt" >> $oldpromptfile
^
in . (source) call of file “/home/wilfred/py-envs/app-engine/bin/activate.fish”,
called on standard input,
wilfred@Tenor ~/py-envs> fish --version
fish, version 1.23.1
wilfred@Tenor ~/py-envs> virtualenv --version
1.5.1
Things still seem to work as expected, but the prompt doesn't change.
Cheers.
We should update Setuptools to 0.6c10.
Hi,
I'm a big fan of virtualenv and more recently distribute.
I see you've added distribute support to virtualenv recently. Any chance you can also add distribute support to virtualenv boot strapping?
Thanks in advance, Martin.
My postmkvirtualenv looks like:
#!/bin/sh
# This hook is run after a new virtualenv is activated.
easy_install -U setuptools
easy_install pip
and if I create virtualenv with command:
mkvirtualenv myenv --no-site-packages -p `which python`
hooks does not run. If I use following command everything seems fine:
mkvirtualenv --no-site-packages -p `which python` myenv
I use builded from source Python on OSX 10.6
When running the win32 Python from cygwin's bash shell, "virtualenv test" installs "test/Scripts/activate.bat" but not "test/Scripts/activate". It looks like this is because "OSTYPE" is not set in the environment and so the check at virtualenv.py line 866 fails.
As a hack, I check both "OSTYPE" and "TERM" (diff attached). This works for me, but I don't know how universal it is. For example it won't work if running from inside the emacs shell (TERM=emacs).
This seems to work for easy_intall and pip in the new virtualenv, I'm not sure if there are other issues.
Hello,
I did a quick search on http://virtualenv.openplans.org/ looking for how this project will be migrating to Python 3. Will you guys have a different branch that you create releases out of or will you be doing a direct cut over at some point (and Python 3 users should use 2to3 for now)?
If possible, it would be helpful for packagers like myself to see the information on the documentation site so we know how to package for the project.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=537246
Thanks!
Creating new virtualenv overwrites distutils/init.py: http://paste.pocoo.org/show/157375/
I've looked at the code and I don't understand how to prevent that and what's wrong with my installation (because this does not happens for other people).
ACTIVATE_SH is mentioned in virtualenv but not defined.
1.4.9 on Linux.
Traceback (most recent call last):
File "virtualenv.py", line 1645, in <module>
main()
File "virtualenv.py", line 556, in main
prompt=options.prompt)
File "virtualenv.py", line 645, in create_environment
site_packages=site_packages, clear=clear))
File "virtualenv.py", line 769, in install_python
copy_required_modules(home_dir)
File "virtualenv.py", line 723, in copy_required_modules
dst_filename = change_prefix(filename, dst_prefix)
File "virtualenv.py", line 708, in change_prefix
(filename, prefixes)
AssertionError: Filename /home/apy/.local/lib/python2.6/site-packages/readline.so does not start with any of these prefixes: ['/opt/ActivePython-2.6']
Some packages (pysparse, for example, probably numpy also) want to install include files. Since include/python2.x is symlinked to to system Python's include directory, this usually fails under a virtualenv.
I don't need setuptools/virtualenv or pip (or rather install them on my own).
post commit hook:
set REPOS="%1"
set REV="%2"
cmd /K C:\Projects\trac\Scripts\activate.bat
trac-admin C:\Projects\trac\test changeset added local_repos %REV%
exit 0
this did not work, after a lot of effort it worked with a slight modification:
set REPOS="%1"
set REV="%2"
**::**cmd /K C:\Projects\trac\Scripts\activate.bat
trac-admin C:\Projects\trac\test changeset added local_repos %REV%
exit 0
I placed the virtualenv command in a comment.
I couldn't find the source of the problem, but i think it has something to do with the virtualenv.
The general idea is to be able to have a new virtualenv inherit from existing VEs in the system. So, for instance, if I have a virtualenv with a set of django tools installed and another with some testing tools you could do:
#!bash
./virtualenv.py tmp/ --inherit=/home/nicolas/django_ve/,/testing_ve,/ --no-site-packages
and it will create a virtualenv that has those VEs in its path so that you can have reusable stuff installed only once.
I'm attaching a patch that adds the basic functionality. While it might need improvement it currently works.
Let me know what you think.
This is just a copy of pypy issue577:
https://codespeak.net/issue/pypy-dev/issue577
creating a virtualenv with pypy-1.4 works. Creating a virtualenv with a
virtualenv-pypy does not work (but this self-recursion works with CPython). See
this session: http://paste.pocoo.org/show/297519/
I have fixed the bug in my virtualenv-pypy fork on bitbucket, feel free to merge it upstream.
Virtualenv doesn't work correctly with the default system python (2.6) on Mac OS 10.6 (Snow Leopard).
To reproduce:
This yields:
New python executable in foo/bin/python
ERROR: The executable foo/bin/python is not functioning
ERROR: It thinks sys.prefix is '/System/Library/Frameworks/Python.framework/Versions/2.6' (should be '/private/tmp/virtualenv-1.4.3/foo')
ERROR: virtualenv is not compatible with this system or executable
Notes:
This only happens with python2.6 (the system default). It works fine if you specify python2.5.
sys.prefix seems different between python2.5 and python2.6 on SL
** 2.5
*** /System/Library/Frameworks/Python.framework/Versions/2.5
** 2.6
*** /usr/bin/../../System/Library/Frameworks/Python.framework/Versions/2.6
I 'fixed' the problem for me by modifying virtualenv.py and adding a call to os.path.abspath on the prefix variable before the call to install_name_tool. Below is the diff of my change against the hg trunk:
diff -r 67b57115a9ef virtualenv.py
--- a/virtualenv.py Wed Dec 16 23:46:38 2009 -0600
+++ b/virtualenv.py Wed Dec 23 11:53:33 2009 -0500
@@ -798,6 +798,7 @@
virtual_lib)
# And then change the install_name of the copied python executable
prefix = os.path.abspath(prefix)
try:
call_subprocess(
["install_name_tool", "-change",
Hi, deactivate.bat doesn't unset VIRTUAL_ENV environment variable on Windows, using virtualenv 1.5.1. Linux counterpart deactivate instead does.
C:\Sandbox\python>virtualenv foo
New python executable in foo\Scripts\python.exe
Installing setuptools.....................done.
C:\Sandbox\python>cd foo
C:\Sandbox\python\foo>Scripts\activate.bat
(foo) C:\Sandbox\python\foo>echo %VIRTUAL_ENV%
C:\Sandbox\python\foo
(foo) C:\Sandbox\python\foo>Scripts\deactivate.bat
C:\Sandbox\python\foo>echo %VIRTUAL_ENV%
C:\Sandbox\python\foo
fix: add after line 10
kw = {}
Virtualenv should support Python 3.
i'm missing something to just get a object for a virtualenv, and manage creation as well as installing/uninstalling/updating packages
it would be nice to have some kind of VirtualEnv object featuring methods to easy_install or pip_install stuff
i made a crude prototype that's using subprocess at http://bitbucket.org/RonnyPfannschmidt/virtualenvmanager/
pypy does not work with virtualenv 1.4.9.
Currently, I'm maintaining a branch to make it working, it would be nice if it were possible to merge it:
http://bitbucket.org/antocuni/virtualenv-pypy/
#!python
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv --distribute --no-site-packages /tmp/v2New python executable in /tmp/v2/bin/python
install_name_tool: for architecture i386 object: /tmp/v2/bin/python malformed object (unknown load command 4)
Could not call install_name_tool -- you must have Apple's development tools installed
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv", line 9, in <module>
load_entry_point('virtualenv==1.4.9', 'console_scripts', 'virtualenv')()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv.py", line 534, in main
use_distribute=options.use_distribute)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv.py", line 617, in create_environment
site_packages=site_packages, clear=clear))
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv.py", line 811, in install_python
py_executable])
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv.py", line 595, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command install_name_tool -change /Library/Frameworks/Python.fra...ython @executable_path/../.Python /tmp/v2/bin/python failed with error code 1
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv --version
1.4.9
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/python --version
Python 2.7
I used ActivePython 2.7.0.1 - but I do believe this also reproduces on Python 2.7 64-bit dmg. This can only be reproduced on 10.5 (neither 10.4 nor 10.6).
In 1.3.4 the support-files aren't installed (e.g. when using pip) because of the package_data hack in setup.py. I worked on a general fix in http://bitbucket.org/jezdez/virtualenv-packaging/.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.