Pip 1.2.x fails to completely install NumPy (OSX global install) #707

Closed
Sharpie opened this Issue Oct 19, 2012 · 28 comments

Projects

None yet

10 participants

@Sharpie
Sharpie commented Oct 19, 2012

After running pip install numpy a subsequent pip install scipy fails complaining about missing files:

numpy.distutils.npy_pkg_config.PkgNotFound: Could not find file(s) ['/usr/local/lib/python2.7/site-packages/numpy/core/lib/npy-pkg-config/npymath.ini']

This error has been reported on Stackoverflow and to a handful of blogs and mailing lists where it has been mentioned that running setup.py directly results in a complete installation.

Upgrading to the current HEAD version of Pip does not help. Downgrading to Pip 1.1 and re-installing NumPy results in a successful SciPy install.

Also, using Pip 1.2.x to install the NumPy 1.7.x pre-releases doesn't help, so this looks like it may be a Pip regression.

Other system details:

  • OS X 10.7.5
  • XCode Command Line Tools for 4.5.1 (no XCode.app installed)
  • Python 2.7.3 installed via Homebrew
@qwcode
Contributor
qwcode commented Oct 20, 2012

I just did this in a virtualenv and it worked, but I see in the stackoverflow, they noticed that as well.
(btw, I had to fumble a bit to get blas/lapack installed)

so then I did it as root with no virtualenv, and it worked.
so then I did it via sudo with no virtualenv, and it worked.

so, I can't recreate this. I'm on ubuntu.

did you notice if npymath.ini was literally missing, or maybe just not readable by the current user?

@Sharpie
Sharpie commented Oct 20, 2012

did you notice if npymath.ini was literally missing, or maybe just not readable by the current user?

It was literally missing. In fact, the whole site-packages/numpy/core/lib subdirectory wasn't there. On a successful installation, the directory should contain:

➜  ~  tree /usr/local/lib/python2.7/site-packages/numpy/core/lib
/usr/local/lib/python2.7/site-packages/numpy/core/lib
├── libnpymath.a
└── npy-pkg-config
    ├── mlib.ini
    └── npymath.ini

1 directory, 3 files
@Sharpie
Sharpie commented Oct 21, 2012

I ran a git bisect and found that 667ace7 is the first version of pip that fails to install all the files properly.

I'm not familiar enough with Pip to speculate on why this causes the break, but I did notice two interesting things:

  • I assume the implementation details of the tempfile module have subtle cross-platform differences. This could explain why the build works on Linux.
  • Builds inside virtualenv appear not to use temporary directories. This could explain why the build is reported to work when virtualenv is being used.
@qwcode
Contributor
qwcode commented Oct 24, 2012

@pnasrat you on a mac over there? maybe you could recreate this?

@pete23
pete23 commented Nov 14, 2012

I can recreate this at will, but know nowt about pip. So if someone can tell me what flags etc to run to get useful trace output let me know.

@pnasrat
Contributor
pnasrat commented Nov 14, 2012

Having the bisect work is probably enough to fiddle with. I'll try take a look later this week, but about to move countries so v. busy.

@Sharpie Sharpie referenced this issue in Homebrew/legacy-homebrew Dec 18, 2012
Closed

pip3 fails with error code 1 (every time) #16632

@samueljohn

Workaround if you are on a Mac:
You may want to try my homebrew tap with NumPy (incl. umfpack/amd,Accelerate.framework) and SciPy formulae:

brew tap samueljohn/python
brew install numpy
brew install scipy

This approach uses the setup.py directly.

@rgommers
rgommers commented Jan 6, 2013

In installed-files.txt I get:

....
../numpy/polynomial/tests/test_chebyshev.py
../numpy/distutils/tests/f2py_f90_ext/src/foo_free.f90
../numpy/core/include/numpy/_numpyconfig.h
../numpy/core/include/numpy/__multiarray_api.h727 ../numpy/core/include/numpy/multiarray_api.txt
../numpy/core/include/numpy/__ufunc_api.h
../numpy/core/include/numpy/ufunc_api.txt
../../../../../../../../../private/var/folders/Uu/UuXfo1NLFae4yyYpsCz-XE+++TI/-Tmp-/pip-build/numpy/numpy/core/lib/npy-pkg-config/npymath.ini
../../../../../../../../../private/var/folders/Uu/UuXfo1NLFae4yyYpsCz-XE+++TI/-Tmp-/pip-build/numpy/numpy/core/lib/npy-pkg-config/mlib.ini
./
dependency_links.txt
PKG-INFO
SOURCES.txt
top_level.txt
../../../../bin/f2py
../../../../../../../../../private/var/folders/Uu/UuXfo1NLFae4yyYpsCz-XE+++TI/-Tmp-/pip-build/numpy/numpy/core/lib/libnpymath.a

So the files that have to end up in numpy/core/lib get built correctly, but install_dir is messed up.

The two numpy.distutils commands used are install_clib and add_npy_pkg, see around line 655 of numpy/core/setup.py. core/lib is the only place in numpy where those are used, but other packages may rely on them too. I checked that in those commands no absolute paths are used anywhere; they must be added by pip somewhere.

@rgommers
rgommers commented Jan 6, 2013

What's the plan here by the way? I see that pip 1.3 release is planned sometime soon (according to release schedule on pip Pypi page). If no one has time to investigate, would you consider reverting the building in a temp dir commits?

@qwcode
Contributor
qwcode commented Jan 6, 2013

I just marked this as a release blocker before 1.3 comes out.
I'll investigate this.

@rgommers
rgommers commented Jan 6, 2013

@qwcode thanks!

@qwcode
Contributor
qwcode commented Jan 16, 2013

ok, here's what I was able to recreate on OSX:

  • virtualenv install (pip-1.2.1): worked
  • root/global install (pip-1.1): worked
  • root/global install (pip-develop): numpy/core/lib was missing as reported
  • root/global install (pip-develop with single-line patch to use v1.1 style build dir): worked

the offending diff from 1.1 to 1.2 is this:

1.1:    build_prefix = os.path.join(os.getcwd(), 'pip-build')
1.2:   build_prefix = os.path.join(tempfile.gettempdir(), 'pip-build')

not sure why this is a problem yet, though.

@qwcode
Contributor
qwcode commented Jan 16, 2013

ok, think I found the issue. tmp dir base paths on OSX are symlinks.

tmp -> private/tmp
var -> private/var

after using os.path.realpath on our build_prefix, the global numpy install worked using pip develop branch.

working on pull now...

@qwcode
Contributor
qwcode commented Jan 16, 2013

can others try the fix in pull #768, and let me know if it works for them.

@jezdez
Contributor
jezdez commented Jan 16, 2013

@qwcode The patch looks good to go.

@qwcode qwcode closed this Jan 16, 2013
@rgommers

That fixes the issue for me. Thanks @qwcode.

@jmcfarlane jmcfarlane added a commit to jmcfarlane/pip that referenced this issue Feb 20, 2013
@jmcfarlane jmcfarlane Fix build_prefix on osx (swing 2)
There was a recent fix (#768) for issue #707 that fixed the brew
install use case, but not the virtualenv use case.  This commit
consolidates the logic.  This was discovered when testing wheel
generation using qwcode's wheel_install branch.

Testing performed (simplejson, numpy 1.7):

 - osx lion (using virtualenv)
 - osx lion (installed via root)
 - ubuntu lucid (using virtualenv)
 - ubuntu lucid (installed via root)

Reference:
 - pypa#707
 - pypa#768
8cf9976
@argriffing

fwiw I just had this problem on a new mac when I tried to install the development version of numpy off github with pip 1.5 ("In fact, the whole site-packages/numpy/core/lib subdirectory wasn't there.") using homebrew python. I worked around by git cloning numpy and running the setup.py directly instead of using pip. I'm kind of a noob with mac/homebrew/pip/git and with python build/install so I'm not sure I could track down the source of the problem, but I just thought I'd mention it.

@rgommers

pip 1.5.6?

@samueljohn

@argriffing might want to try brew tap homebrew/python and then brew install numpy.

@argriffing

@rgommers yes:

$ which python; which pip; pip --version
/usr/local/bin/python
/usr/local/bin/pip
pip 1.5.6 from /usr/local/Cellar/python/2.7.7_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg (python 2.7)

@samueljohn thanks for the suggestion! Right now I'm not brave enough to attempt to roll back my seemingly successful numpy setup.py installation to try the brew tap way of installing the development branch of numpy. I see that https://github.com/Homebrew/homebrew-python#why-not-pip does not currently include "because when pip tries to use the numpy github source it fails to install the core/lib/ directory" as a "why not pip" entry for numpy.

@patricklaw
Contributor

This appears to still be an issue on 6.x, including the most recent release. I'll look into doing a bisect today to see where it (presumably) regressed again. We're having the issue on linux, not OSX, but our linux tmpdirs are symlinks, so it could be the same problem (and OSX installs grab wheels rather than building from source anyway). Our reproduction case is simple:

<make a py27 virtualenv in `foo` and activate it>
$ pip install -U pip
$ pip --version
pip 6.0.6 from ...
$ pip install numpy
$ ls foo/lib/python2.7/site-packages/numpy/core/lib  # Doesn't exist

Performing the same steps in an alternate virtualenv but pinning pip to 1.5.6 does not reproduce--the core/lib folder is present after installing.

@patricklaw
Contributor

I just did a quick linear scan of published versions and confirmed that this broke in the upgrade from 1.5.6 to 6.0. Which was massive, so it's unclear how to dig further.

@patricklaw
Contributor

I'm bisecting now, should have an exact commit shortly.

@patricklaw
Contributor

Got it, and the commit in question makes sense:

$ git bisect good
01610be0d58bc428646126090cb2905cf219b2f4 is the first bad commit
commit 01610be0d58bc428646126090cb2905cf219b2f4
Author: Donald Stufft <donald@stufft.io>
Date:   Tue Nov 11 19:19:32 2014 -0500

    Use a secure randomized build directory when possible
@dstufft
Member
dstufft commented Jan 22, 2015

Numpy depends on not using a randomized build directory?

@patricklaw
Contributor

This patch fixes the problem:

$ git diff
diff --git a/pip/utils/build.py b/pip/utils/build.py
index 9ffb4ea..9942004 100644
--- a/pip/utils/build.py
+++ b/pip/utils/build.py
@@ -1,5 +1,6 @@
 from __future__ import absolute_import

+import os
 import tempfile

 from pip.utils import rmtree
@@ -14,7 +15,7 @@ class BuildDirectory(object):
             delete = True

         if name is None:
-            name = tempfile.mkdtemp(prefix="pip-build-")
+            name = os.path.realpath(tempfile.mkdtemp(prefix="pip-build-"))
             # If we were not given an explicit directory, and we were not given
             # an explicit delete option, then we'll default to deleting.
             if delete is None:
@dstufft
Member
dstufft commented Jan 22, 2015

Ah, it's the symlink not the randomized that is the problem.

Want to make a PR against develop?

@patricklaw
Contributor

Will do.

@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue Sep 6, 2015
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix:
pypa#707
731545e
@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue Feb 20, 2016
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix:
pypa#707
9e97761
@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue Feb 21, 2016
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix:
pypa#707
42b64e4
@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue Mar 5, 2016
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix:
pypa#707
f1fcf87
@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue Mar 30, 2016
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix:
pypa#707
227e8c7
@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue May 19, 2016
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix:
pypa#707
e59301a
@zvezdan zvezdan added a commit to zvezdan/pip that referenced this issue May 19, 2016
@zvezdan zvezdan Use a realpath for the temporary build directory.
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix: #707

---

*This was migrated from pypa/pip#3079 to reparent it to the ``master``
branch. Please see original pull request for any previous discussion.*
5958656
@dstufft dstufft added a commit that referenced this issue May 20, 2016
@zvezdan @dstufft zvezdan + dstufft Use a realpath for the temporary build directory. (#3701)
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix: #707

---

*This was migrated from pypa/pip#3079 to reparent it to the ``master``
branch. Please see original pull request for any previous discussion.*
4e2c1fa
@waisbrot waisbrot pushed a commit to waisbrot/pip that referenced this issue Jul 5, 2016
@zvezdan zvezdan + Nathaniel Waisbrot Use a realpath for the temporary build directory. (#3701)
Some systems have /tmp symlinked which confuses custom builds, such as
numpy. This ensures that real path is passed and that such builds
resolve their paths correctly during build and install.

Added test for the change and also for the previous related fix: #707

---

*This was migrated from pypa/pip#3079 to reparent it to the ``master``
branch. Please see original pull request for any previous discussion.*
9e1f81c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment