New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Oct 20, 2012

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@Sharpie

Sharpie 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 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

This comment has been minimized.

Show comment
Hide comment
@Sharpie

Sharpie 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.

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Oct 24, 2012

Contributor

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

Contributor

qwcode commented Oct 24, 2012

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

@pete23

This comment has been minimized.

Show comment
Hide comment
@pete23

pete23 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.

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

This comment has been minimized.

Show comment
Hide comment
@pnasrat

pnasrat Nov 14, 2012

Contributor

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.

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.

@samueljohn

This comment has been minimized.

Show comment
Hide comment
@samueljohn

samueljohn Dec 19, 2012

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.

samueljohn commented Dec 19, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rgommers

rgommers 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 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

This comment has been minimized.

Show comment
Hide comment
@rgommers

rgommers 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?

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Jan 6, 2013

Contributor

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

Contributor

qwcode commented Jan 6, 2013

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

@rgommers

This comment has been minimized.

Show comment
Hide comment
@rgommers

rgommers commented Jan 6, 2013

@qwcode thanks!

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Jan 16, 2013

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Jan 16, 2013

Contributor

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...

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Jan 16, 2013

Contributor

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

Contributor

qwcode commented Jan 16, 2013

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

@jezdez

This comment has been minimized.

Show comment
Hide comment
@jezdez

jezdez Jan 16, 2013

Contributor

@qwcode The patch looks good to go.

Contributor

jezdez commented Jan 16, 2013

@qwcode The patch looks good to go.

qwcode added a commit that referenced this issue Jan 16, 2013

Merge pull request #768 from qwcode/issue_707
fix for issue #707 (numpy global installs on OSX)

@qwcode qwcode closed this Jan 16, 2013

@rgommers

This comment has been minimized.

Show comment
Hide comment
@rgommers

rgommers Jan 19, 2013

That fixes the issue for me. Thanks @qwcode.

rgommers commented Jan 19, 2013

That fixes the issue for me. Thanks @qwcode.

jmcfarlane added a commit to jmcfarlane/pip that referenced this issue Feb 20, 2013

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
@argriffing

This comment has been minimized.

Show comment
Hide comment
@argriffing

argriffing Jun 29, 2014

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.

argriffing commented Jun 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@rgommers

rgommers Jun 30, 2014

pip 1.5.6?

rgommers commented Jun 30, 2014

pip 1.5.6?

@samueljohn

This comment has been minimized.

Show comment
Hide comment
@samueljohn

samueljohn Jun 30, 2014

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

samueljohn commented Jun 30, 2014

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

@argriffing

This comment has been minimized.

Show comment
Hide comment
@argriffing

argriffing Jun 30, 2014

@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.

argriffing commented Jun 30, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@patricklaw

patricklaw Jan 22, 2015

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.

Contributor

patricklaw commented Jan 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@patricklaw

patricklaw Jan 22, 2015

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.

Contributor

patricklaw commented Jan 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@patricklaw

patricklaw Jan 22, 2015

Contributor

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

Contributor

patricklaw commented Jan 22, 2015

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

@patricklaw

This comment has been minimized.

Show comment
Hide comment
@patricklaw

patricklaw Jan 22, 2015

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
Contributor

patricklaw commented Jan 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 22, 2015

Member

Numpy depends on not using a randomized build directory?

Member

dstufft commented Jan 22, 2015

Numpy depends on not using a randomized build directory?

@patricklaw

This comment has been minimized.

Show comment
Hide comment
@patricklaw

patricklaw Jan 22, 2015

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:
Contributor

patricklaw commented Jan 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 22, 2015

Member

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

Want to make a PR against develop?

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

This comment has been minimized.

Show comment
Hide comment
@patricklaw

patricklaw Jan 22, 2015

Contributor

Will do.

Contributor

patricklaw commented Jan 22, 2015

Will do.

zvezdan added a commit to zvezdan/pip that referenced this issue Sep 6, 2015

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

zvezdan added a commit to zvezdan/pip that referenced this issue Feb 20, 2016

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

zvezdan added a commit to zvezdan/pip that referenced this issue Feb 21, 2016

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

zvezdan added a commit to zvezdan/pip that referenced this issue Mar 5, 2016

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

zvezdan added a commit to zvezdan/pip that referenced this issue Mar 30, 2016

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

zvezdan added a commit to zvezdan/pip that referenced this issue May 19, 2016

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

zvezdan added a commit to zvezdan/pip that referenced this issue May 19, 2016

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.*

dstufft added a commit that referenced this issue May 20, 2016

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.*

waisbrot pushed a commit to waisbrot/pip that referenced this issue Jul 5, 2016

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.*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment