Hi, I'd like to drive pythonz from another program (specifically, I was thinking of adding pythonz as a dependency of pew).

For this I tried to install pythonz with the setup.py, and apparently it can work even without running the pythonz-install step (you have to workaround some errors, but it's doable).

I'd prefer if there was no pythonz-install step altogether, it should be relatively easy to adapt it:

just use the INSTALLER_ROOT ( os.path.dirname(os.path.abspath(__file__)) works just fine even inside a setuptools-installed source code), instead of the PYTHONZ_ROOT to get the path for patches, shell scripts, etc. (the MANIFEST.in apparently already ships the needed ).

The update command then wouldn't obviously relied upon anymore (but as long as it can be securely downloaded, a file that specifies the new versions and the needed patches could still be downloaded into PYTHONZ_ROOT, but this is an even bigger change).

Failing this, it'd be nice to at least be able to run a silent installation (without having to muck with the stdout). The installation message asks the user to load the supplied bashrc, but I'm also not sure: it seems mostly to be useful wrappers for completion and the like, but I don't know if by avoiding to use them I might stumble into other problems.

It'd also be useful to have it available on Pypi: Pythonbrew is already there. (This should be another issue, and I could do it myself, but it's probably best to discuss this in advance as well)

I don't know the history of Pythonbrew/Pythonz, so I'm not sure about the policy that you have about such changes. I had a look at the codebase, and apparently there're things kept only for compatibility with older python versions (as the host interpreter for pythonz, I mean), and since what I'm proposing might be controversial I haven't prepared any PR nor tweaked any line of code before opening this issue. (I'd also like to get rid of the code that uses shell=True in subprocess.call for example)

Sorry if this is a sort of brain-dump and not properly structured.

When installing Stackless Python version 3.3.5, I get the following error:

$ pythonz install -t stackless 3.3.5 
Downloading stackless-335-export.tar.bz2 as /Users/lgw4/.pythonz/dists/stackless-335-export.tar.bz2
########################################################################## 100%
Extracting stackless-335-export.tar.bz2 into /Users/lgw4/.pythonz/build/Stackless-3.3.5

This could take a while. You can run the following command on another shell to track the status:
  tail -f /Users/lgw4/.pythonz/log/build.log

Installing Stackless-3.3.5 into /Users/lgw4/.pythonz/pythons/Stackless-3.3.5
Traceback (most recent call last):
  File "/Users/lgw4/.pythonz/scripts/pythonz/installer/pythoninstaller.py", line 195, in install
    self.make()
  File "/Users/lgw4/.pythonz/scripts/pythonz/installer/pythoninstaller.py", line 342, in make
    s.check_call(make)
  File "/Users/lgw4/.pythonz/scripts/pythonz/util.py", line 298, in check_call
    raise ShellCommandException('%s: failed to `%s`' % (returncode, cmd))
ShellCommandException: 2: failed to `make -j4`
ERROR: Failed to install Stackless-3.3.5. Check /Users/lgw4/.pythonz/log/build.log to see why.

Here is a gist for the build.log: https://gist.github.com/lgw4/d47947929cba58196d5f

I'm on OS X 10.9.3.

Please add to the list of installable Python interpreters :-)
Thanks!

There is a patch which is (mostly) duplicated in the patches directory.

https://github.com/saghul/pythonz/blob/5fb5a3cef906e1eac7fedafbc66f854f978461d5/pythonz/patches/all/common/patch-setup.py.diff
https://github.com/saghul/pythonz/blob/5fb5a3cef906e1eac7fedafbc66f854f978461d5/pythonz/patches/all/python24/patch-setup.py.diff

One of them should probably be removed.

It would be immensely time saving if instead of ~/.pythonz/pythons/PyPy-1.9/bin/ipython I could do pz pypy-1.9 ipython or pz pypy ipython (automatically selects the latest pypy). Ideally, it would also provide bash autocompletion for completing of both the Python version and the command to execute.

It'd be nice to be able to provide an installation directory, for scriptability purposes :)

While working on the checksums PR, I realized that there are some python versions that aren't currently covered:

• Newer stackless versions
• Portable Pypy
• Precompiled ARM versions for Pypy
• Ironpython
• Conda distribution? (actually, this is the same version as Cpython, but it has a "different stdlib" and doesn't integrate properly with pip, so I guess that pyenv has it for that reason... but maybe now that venv and ensurepip are in the stdlib Conda is just legacy? not sure)
• I just realized that there might be something else as well that is missing, like Nuitka

I don't actually have a need for these versions, I just wanted to note this stuff down

I was having gcc errors in my Arch Linux system which always ended like this:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes  -I. -I./Include   -DPy_BUILD_CORE  -c ./Modules/xxsubtype.c -o Modules/xxsubtype.o
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes  -I. -I./Include   -DPy_BUILD_CORE -DSVNVERSION=\"`LANG=C svnversion .`\" -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
gcc: error: directory": No such file or directory
make: *** [Modules/getbuildinfo.o] Error 1

and in pythonz

ShellCommandException: 2: failed to `make -j8`

But then I switched to a clean ISO Linux Mint and these errors didn't appear. Actually first I got a syntax error identical to #21, but when I applied the corresponding patch the built went on successfully. I tried to force -j1 just in case there was some strange race condition but the result was the same.

OTOH, it is not related to the bug but interestingly enough tail -f didn't follow file changes in Mint.

Default Pythonz 2.7.5 build only has a few builtin modules enabled.

'__builtin__', '__main__', '_ast', '_codecs', '_sre', '_symtable', '_warnings', '_weakref', 'errno', 'exceptions', 'gc', 'imp', 'marshal', 'posix', 'pwd', 'signal', 'sys', 'thread', 'xxsubtype', 'zipimport'

My out-of-the-box Python2.7.3 package on Ubuntu12.04:

'__builtin__', '__main__', '_ast', '_bisect', '_codecs', '_collections', '_functools', '_hashlib', '_locale', '_random', '_socket', '_sre', '_ssl', '_struct', '_symtable', '_warnings', '_weakref', 'array', 'binascii', 'cPickle', 'cStringIO', 'cmath', 'errno', 'exceptions', 'fcntl', 'gc', 'grp', 'imp', 'itertools', 'marshal', 'math', 'operator', 'posix', 'pwd', 'select', 'signal', 'spwd', 'strop', 'sys', 'syslog', 'thread', 'time', 'unicodedata', 'xxsubtype', 'zipimport', 'zlib'

I read a lot of makefile/installer source code, but I'm still unsure how to enable more builtin modules in pythonz.

This ones: https://bitbucket.org/squeaky/portable-pypy/downloads

Reference: https://github.com/squeaky-pl/portable-pypy

pythonbrew has some extra patches pythonz doesn't at this point. They are for old pythons, but we should have them.

I'm currently using pythonz in a provisioning tool and it's messing up with the output of the provisioning tool.

Remove the --dev option to the update command as well.

Please, add python 3.4 support

I might try to implement this tomorrow, by taking inspiration from something like this:

http://code.activestate.com/recipes/83208-resuming-download-of-a-file/

but in the meanwhile I wanted to note it down (also because tomorrow I might end up doing something differently and postpone it)

I find that a production Python setup lacks the _bsddb module, so I apt-get install libdb4.8-dev and then want to rebuild Python 2.7.6 to have that module. But pythonz refuses to install it because it's already installed, and there's no flag to force it. I would prefer not to uninstall it and then start a build from scratch, because my existing Python is in use and would presumably be broken in the meantime.

So ideally I'd want to force a reinstall of 2.7.6, which would go through the whole build and then only affect the system at the end, replacing the previous Python install. Something like sudo-pythonz reinstall 2.7.6 or sudo-pythonz install --reinstall 2.7.6

I could probably fudge this with a whole second pythonz install (export PYTHONZ_ROOT=/usr/local/pythonz2) but that seems unnecessarily messy.

As of a1224c4 pythonz bash completion requires Bash 4 because of the use of associative arrays. Under older Bash this is emitted on login (or whenever $HOME/.pythonz/etc/bashrc is executed):

-bash: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
-bash: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]

Since (at least) the last update the versions list appears unsorted:

○ pythonz list -a
# Available Python versions
  # cpython:
     3.1.3
     3.1.2
     3.1.1
     3.1.5
     3.1.4
     2.4.3
     2.4.2
     2.4.1
     2.4.6
     2.4.5
     2.4.4
     2.6.9
     2.6.8
     2.6.1
     2.6.3
     2.6.2
     2.6.5
     2.6.4
     2.6.7
     2.6.6
     3.3.1
     3.3.0
     3.3.3
     3.3.2
     3.3.5
     3.3.4
     3.3.6
     3.0.1
     2.7.10
     3.2
     3.0
     3.1
     3.5.0
     2.7
     2.6
     2.5
     2.4
     2.5.6
     2.5.4
     2.5.5
     2.5.2
     2.5.3
     2.5.1
     3.4.2
     3.4.3
     3.4.0
     3.4.1
     2.7.8
     2.7.9
     2.7.4
     2.7.5
     2.7.6
     2.7.7
     2.7.1
     2.7.2
     2.7.3
     3.2.4
     3.2.5
     3.2.1
     3.2.2
     3.2.3
  # stackless:
     3.1.3
     2.6.5
     2.7.2
     3.2.5
     3.3.5
     3.2.2
  # pypy:
     4.0.0
     2.4.0
     2.0.2
     2.0.1
     2.6.1
     2.3.1
     1.8
     1.9
     2.2.1
     2.6.0
     2.3
     2.2
     2.1
     2.0
     2.5.0
     2.5.1
  # pypy3:
     2.3.1
     2.4.0
  # jython:
     2.7.0
     2.5.2
     2.5.3
     2.5.0
     2.5.1

When trying to install CPython 2.7.10, pythonz fails because the generated URL is http://www.python.org/ftp/python/2.7.1/Python-2.7.10.tgz, not http://www.python.org/ftp/python/2.7.10/Python-2.7.10.tgz. Looks like it is something to do with base_version in pythoninstaller.py.

Full output here: https://gist.github.com/lgw4/657e69960e8ee99b4cc8

Scenario: a build system reads a file in a repository to know which version of Python is required. The build system uses pythonz to install that version, unless it already exists. Then the build system proceeds with other build tasks.

The ideal solution would be that pythonz install 2.7.9 has a return code of 0 whenever CPython 2.7.9 already exists, so that installation is idempotent. However, that might break behavior someone currently depends on.

An alternative is an additional parameter, like pythonz install 2.7.9 --no-error-if-installed (or maybe --idempotent if shorter is better). That would have a return code of 0 if CPython 2.7.9 already exists. I get my idempotent command but current behavior remains.

My current quick fix is to alter the behavior of locate so that it can be used as a test whether a version exists (pull request pending). Then my code can do the following:

$VERSION = 2.7.9
if ! pythonz locate $VERSION; then
    pythonz install $VERSION
fi

Pythonbrew is deprecated, but its author unexplicably still commits/merges a few changes:

utahta/pythonbrew@2b87183

I frankly don't like that, since it leads to duplicated effort and causes resources to be spread more thinly.

Alas, the change I linked to could benefit Pythonz (more tests and travis integration)

Title says all.

$ lsb_release -a
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.4 (Final)
Release: 6.4
Codename: Final

$ rpm -q python
python-2.6.6-37.el6_4.x86_64

[user@machine /home/user]$ pythonz install 2.5
Use the previously fetched /inco/home01/user/.pythonz/dists/Python-2.5.tgz
Extracting Python-2.5.tgz into /inco/home01/user/.pythonz/build/CPython-2.5

This could take a while. You can run the following command on another shell to track the status:
tail -f /inco/home01/user/.pythonz/log/build.log

Installing CPython-2.5 into /inco/home01/user/.pythonz/pythons/CPython-2.5
ERROR: Failed to patch /inco/home01/user/.pythonz/build/CPython-2.5.
1: failed to (patch -p0 < /inco/home01/user/.pythonz/patches/all/python25/patch-svnversion.patch) >> '/inco/home01/user/.pythonz/log/build.log' 2>&1

Would it be at all desirable/feasible to have pythonz install unique versions of CPython (and Stackless, I suppose) binaries based on the current system architecture?

I'm thinking here of a very traditional UNIX network environment, where a user might have a single home directory that's NFS-shared among machines with various architectures.

I currently handle this situation by setting PYTHONZ_ROOT to a value that has "uname -smp" interpolated. I.e. I keep a separate pythonz directory for each of the the various architectures in use.

$ pythonz version
1.10.0

$ pythonz update
Downloading pythonz-latest.tgz as /usr/local/pythonz/dists/pythonz-latest.tgz
Traceback (most recent call last):
File "/usr/local/pythonz/scripts/pythonz_main.py", line 3, in
pythonz.main()
File "/usr/local/pythonz/scripts/pythonz/init.py", line 42, in main
command.run(args[1:])
File "/usr/local/pythonz/scripts/pythonz/commands/init.py", line 22, in run
self.run_command(options, args)
File "/usr/local/pythonz/scripts/pythonz/commands/update.py", line 27, in run_command
Downloader.fetch(PYTHONZ_UPDATE_URL, download_file)
TypeError: fetch() takes exactly 4 arguments (3 given)

Broken after today commit.

Fix please.

2.5 was released on Tue, Feb 3rd.
See http://morepypy.blogspot.de/2015/02/pypy-250-released.html .
I'm seeing it used on Travis CI already, that's why I'm asking.

Add a list_version command thus users would know which versions are supported by pythonz.

Hello!

It'd be quite useful if pythonz asked to install dependencies (espicially if it's run as root), for example zlib is rather important for installing pip, and openssl is also necessary to get packages from PyPI (because of HTTPS).

It seems that the up-to-date dependencies are always nicely listed here: http://www.linuxfromscratch.org/blfs/view/svn/general/python3.html
http://www.linuxfromscratch.org/blfs/view/svn/general/python2.html

I know it is a bit of a feature creep, but doing a simple distribution detection and running

apt-get -y install zlib1g-dev libssl-dev libexpat1-dev libffi-dev or the yum/pacman/whatever equivalent does look fairly maintainable, and probably won't turn into a nightmare :)

This would be a sister issue to #73

Basically, while working on that, I realized that for a lot of error conditions, the current action is to sys.exit(1)

That's fine for application level code, but not so for a library.

The code that I added for the checksums PR for example prefers to raise an exception rather than terminating right away, but I refrained from modifying existing code... preferring to hear your opinion before making any such changes

It seems like install does not install all stuff (the patches dir for example)

root /tmp # curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  2596  100  2596    0     0   2662      0 --:--:-- --:--:-- --:--:--  2662
Downloading https://github.com/saghul/pythonz/tarball/master
######################################################################## 100.0%
Extracting /usr/local/pythonz/dists/pythonz-latest.tar.gz
Installing pythonz into /usr/local/pythonz

Well-done! Congratulations!

The pythonz is installed as:

  /usr/local/pythonz

After that, exit this shell, start a new one, and install some fresh
pythons:

  pythonz install 2.7.2
  pythonz install 3.2

For further instructions, run:

  pythonz help

The default help messages will popup and tell you what to do!

Enjoy pythonz at /usr/local/pythonz!!

root /tmp # /usr/local/pythonz/bin/pythonz install 2.6.6      
Use the previously fetched /root/.pythonz/dists/Python-2.6.6.tgz
Extracting Python-2.6.6.tgz into /root/.pythonz/build/CPython-2.6.6

This could take a while. You can run the following command on another shell to track the status:
  tail -f /root/.pythonz/log/build.log

Installing CPython-2.6.6 into /root/.pythonz/pythons/CPython-2.6.6
ERROR: Failed to patch `/root/.pythonz/build/CPython-2.6.6`.
2: failed to `(patch -p0 < /root/.pythonz/patches/all/common/patch-setup.py.diff) >> '/root/.pythonz/log/build.log' 2>&1`
root /tmp # ls -al /root/.pythonz 
total 28
drwxr-xr-x  7 root root 4096 Nov 14 11:15 .
drwx------ 22 root root 4096 Nov 14 11:18 ..
drwxr-xr-x  3 root root 4096 Nov 14 11:18 build
drwxr-xr-x  2 root root 4096 Nov 14 11:15 dists
drwxr-xr-x  2 root root 4096 Nov 14 11:13 etc
drwxr-xr-x  2 root root 4096 Nov 14 11:15 log
drwxr-xr-x  2 root root 4096 Nov 14 11:14 pythons

curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2596 100 2596 0 0 8850 0 --:--:-- --:--:-- --:--:-- 12187
Downloading https://github.com/saghul/pythonz/tarball/master

################################################################## 100.0%

Extracting /home/xenoterracide/.pythonz/dists/pythonz-latest.tar.gz
Installing pythonz into /home/xenoterracide/.pythonz
Traceback (most recent call last):
File "/home/xenoterracide/.pythonz/dists/saghul-pythonz-5b355ac/pythonz_install.py", line 3, in
from pythonz.installer import install_pythonz, upgrade_pythonz, systemwide_pythonz
File "/home/xenoterracide/.pythonz/dists/saghul-pythonz-5b355ac/pythonz/init.py", line 9, in
from pythonz.util import makedirs
File "/home/xenoterracide/.pythonz/dists/saghul-pythonz-5b355ac/pythonz/util.py", line 100
except OSError, e:
^
SyntaxError: invalid syntax
Failed to install pythonz.

Example:

pythonz install --url https://hg.python.org/cpython/archive/tip.tar.gz 3.5.0dev

CPython 2.7.10 and 3.5.0 are built without zlib on OS X 10.11. This prevents making virtualenvs with these versions, which is the reason I use pythonz. Log file here: https://gist.github.com/lgw4/e462640bfd1aa8614013
OS X 10.11 (15A284)
Xcode 7.0.1
Build version 7A1001

Interrupted downloads leave behind unfinished files, and these unfinished files will cause an error during the next attempt to install the same version:

~$ pythonz install --type cpython 2.6.7
Downloading Python-2.6.7.tgz as /Users/erik.allik/.pythonz/dists/Python-2.6.7.tgz
^CTraceback (most recent call last):                                         7%
...
KeyboardInterrupt

~$ pythonz install --type cpython 2.6.7
Use the previously fetched /Users/erik.allik/.pythonz/dists/Python-2.6.7.tgz
Extracting Python-2.6.7.tgz into /Users/erik.allik/.pythonz/build/CPython-2.6.7
Traceback (most recent call last):
...
IOError: CRC check failed 0x9aa41247L != 0x96b934e8L

It could be useful to have a simple standardized schema for the interpreter names shared among different tools.

For example, tox uses basepython and envlist to choose which version of Python to use.

basepython is used to resolve the envlist names to the actual python interpreters (with some default names available), but ultimately it wants either an interpreter name (resolved with PATH to an executable) or an actual executable path.

This means that, unless you pick generic names like "python3.4", it's not portable among machines. And things like pypy3 won't allow to pick among the different versions of pypy3 (I haven't looked deeply to see all the default basepython names, so I might be wrong)

I think that the best place to do this would be in a tool that actually downloads/manages the python interpreters, like Pythonz.

Another advantage, could be to reuse the same .python-version files created by pyenv, allowing Pythonz (or another tool) to automatically propose the installation of the version specified in that file, is not available already.

The same thing could be done with the tox.ini, if Tox was on board: by parsing it, a tool could detect with Python versions are required for the full test suite, and propose the installation of them.

Pythonz currently outputs a camelcase representation with pythonz list, but otherwise, as an input, only uses the version and the --type command line flag.

a more canonical name would be shorter and could be used as a single argument to be supplied to pythonz. Pyenv names could be a good starting point, but there'd be 2 issues to take care:

• Pyenv doesn't use python-3.5.0, or cpython-3.5.0 but only 3.50 when talking about Cpython versions... it'd be better to be more explicit
• Pyenv has a bunch of -dev versions... I guess that those could be simply ignored?

This is just a proposal/idea... I wanted to discuss this, rather than starting to implement something similar in Pythonz with the risk of not having consensus on it

The PyPy download URL: https://bitbucket.org/pypy/pypy/downloads/pypy-1.9-linux64.tar.bz2

The default Python on Ubuntu 10.04 is Python 2.6.5

Hi, just an heads up since, if you've been busy, you might have missed it.

You noted that you had support for PyPy "CPython, Stackless, PyPy and Jython are supported." when I am doing pythonz list -a PyPy is not available.

When doing pythonz cleanup the build directory is removed, so all debug symbols are gone and debugging C extensions properly is no longer possible. Maybe a --all modifier would make sense, mentioning the debug symbols thing in the helper text.

pythonz install 2.6.8

this fails:

python -c "import bz2"
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named bz2

originally I was trying to:

pip install pytz==2012h

and ran into the issue.

It would be nice if pythonz could also support older python versions then 2.6.

$ pythonz install 2.7.9
Use the previously fetched /Users/robinho/.pythonz/dists/Python-2.7.9.tgz
Extracting Python-2.7.9.tgz into /Users/robinho/.pythonz/build/CPython-2.7.9

This could take a while. You can run the following command on another shell to track the status:
  tail -f /Users/robinho/.pythonz/log/build.log

Installing CPython-2.7.9 into /Users/robinho/.pythonz/pythons/CPython-2.7.9

Installed CPython-2.7.9 successfully.
$ ~/.pythonz/pythons/CPython-2.7.9/bin/python get-pip.py
Traceback (most recent call last):
  File "get-pip.py", line 20204, in <module>
    main()
  File "get-pip.py", line 152, in main
    bootstrap(tmpdir=tmpdir)
  File "get-pip.py", line 82, in bootstrap
    import pip
zipimport.ZipImportError: can't decompress data; zlib not available

Another example:

$ ~/.pythonz/pythons/CPython-2.7.9/bin/python
Python 2.7.9 (default, Mar  6 2015, 18:39:28)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import zlib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named zlib
>>>

But there are zlib installed:

$ pkg-config --list-all | grep -i zlib
zlib            zlib - zlib compression library
$ pkg-config --modversion zlib
1.2.5

Latest pythonz version on Ubuntu 13.04.

After running:

curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash

Installation seems to be successful but I noticed this in the output:

tar: write error

Uninstalling fails with:

  File "/home/edliaw/.pythonz/pythons/CPython-2.7.5/lib/python2.7/shutil.py", line 254, in rmtree
    os.rmdir(path)
OSError: [Errno 39] Directory not empty: '/home/edliaw/.pythonz/pythons/CPython-2.7.5/lib/python2.7/lib-dynload'

lib-dynload is in fact empty when I check it, though. Perhaps a solution is to call shutil.rmtree (called in rm_r in util.py) with ignore_errors=True or to specify a function for onerror that only prints a warning message.

Hey guys, excellent work.
Is there any plans to version this project properly? maybe start creating tags?

Thanks!

Hi,

I get the following error message (I think from adding in .bashrc)
I followed this: http://stackoverflow.com/questions/12626370/virtualenv-shell-errors
but no result.
No effect setting $VIRTUALENVWRAPPER_HOOK_DIR as .virtualenvs in .bashrc. It is simply ignored.
Any idea?

stevedore.extension error calling 'user_scripts': [Errno 2] No such file or directory: '/home/toniher/$VIRTUALENVWRAPPER_HOOK_DIR/initialize'
stevedore.extension [Errno 2] No such file or directory: '/home/toniher/$VIRTUALENVWRAPPER_HOOK_DIR/initialize'
Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-packages/stevedore-0.8-py2.6.egg/stevedore/extension.py", line 126, in _invoke_one_plugin
response_callback(func(e, _args, *_kwds))
File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper-3.7-py2.6.egg/virtualenvwrapper/hook_loader.py", line 182, in invoke
ext.plugin(args)
File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper-3.7-py2.6.egg/virtualenvwrapper/user_scripts.py", line 143, in initialize
make_hook(get_path('$VIRTUALENVWRAPPER_HOOK_DIR', filename), comment)
File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper-3.7-py2.6.egg/virtualenvwrapper/user_scripts.py", line 124, in make_hook
f = open(filename, 'w')
IOError: [Errno 2] No such file or directory: '/home/toniher/$VIRTUALENVWRAPPER_HOOK_DIR/initialize'
stevedore.extension error calling 'project': [Errno 2] No such file or directory: '/home/toniher/$VIRTUALENVWRAPPER_HOOK_DIR/premkproject'
stevedore.extension [Errno 2] No such file or directory: '/home/toniher/$VIRTUALENVWRAPPER_HOOK_DIR/premkproject'
Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-packages/stevedore-0.8-py2.6.egg/stevedore/extension.py", line 126, in _invoke_one_plugin
response_callback(func(e, _args, *_kwds))
File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper-3.7-py2.6.egg/virtualenvwrapper/hook_loader.py", line 182, in invoke
ext.plugin(args)
File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper-3.7-py2.6.egg/virtualenvwrapper/project.py", line 36, in initialize
comment)
File "/usr/local/lib/python2.6/dist-packages/virtualenvwrapper-3.7-py2.6.egg/virtualenvwrapper/user_scripts.py", line 124, in make_hook
f = open(filename, 'w')
IOError: [Errno 2] No such file or directory: '/home/toniher/$VIRTUALENVWRAPPER_HOOK_DIR/premkproject'

I am not able to install CPython 2.4 (I tried 2.4.1 and 2.4.6 with identical results) in Arch Linux. It seems it is using a wrong setup.py, because it contains a with block (which was introduced in 2.5).

  File "./setup.py", line 253
    with open(tmpfile) as fp:
            ^
SyntaxError: invalid syntax
make: *** [sharedmods] Error 1