Installing numpy with setupegg.py does indeed install numpy as an egg, but it does not solve the problem I describe here (tested with numpy-1.3.0rc1, and the rest as described below). If numpy is listed as a dependency for another package which is installed into a virtual environment, setuptools tries to download and install numpy instead of just adjusting the easy_install.pth file.
Hmm. I tried to install my packages without a virtual environment, and that works ok. So it must be a problem in the interaction between setuptools and virtualenv... I'll cross post this in the virtualenv mailing list...
----- "David Cournapeau" firstname.lastname@example.org wrote:
Christian Marquardt wrote:
I've run into the following problem:
- I have numpy (v1.3.0b1) successfully installed in my system's site-packages (for Python 2.5.2).
- I have setup a virtual environment (with virtualenv 1.3.3) which uses the systems site-packages; in particular, I can load numpy when working in that environment.
- I have a (namespaced) package which requires numpy (via "install_requires = ['numpy']" in the setup() of setuptools (v0.6c9, as coming with virtualenv), and try to build that in the virtual environment using the usual python setup.py install.
- When processing the requirements for the packages, setuptools downloads a fresh copy from numpy 1.3.0b1 from Pypi and tries to install it - although numpy is already available in the
wide site-packages directory.
To me, that's a bug, but I would like to know if it is a bug in
(which might not support setuptools in the correct way) or
which tries to install an already existing package.
If you want setuptools 'support', I think you should install numpy through the setupegg.py script.