Skip to content
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

Use a realpath for the temporary build directory. #3079

Closed
wants to merge 1 commit into from

Conversation

zvezdan
Copy link
Contributor

@zvezdan zvezdan commented Sep 6, 2015

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

Review on Reviewable

@zvezdan
Copy link
Contributor Author

zvezdan commented Sep 6, 2015

Let me provide more information and rationale for this change and tests.
Apparently, this bug resurfaced multiple times in pip history:
#707

The last fix in version 6.* still didn't fix the problem.
I recently debugged an issue that showed up only on build machines while it never showed on my Linux desktop. The symptom was that scipy couldn't find *.ini files from the successfully built numpy package because they were missing from the expected location.
After examining the artifacts and debugging the build I found out that the numpy gets built either in a virtual environment or in a wheel as follows:

...
/path/to/venv_or_wheel/numpy/core/somefile.py
...
/path/to/venv_or_wheel/numpy/core/somedir
...
path/to/venv_or_wheel/export/tmp/pip-sb4Nm5-build/numpy/core/lib/npy-pkg-config/npymath.ini
... another file like this
... one library from lib missing

These files should have been in

/path/to/venv_or_wheel/numpy/core/lib/...

While debugging the build I also observed that the paths for these *.ini files were misconfigured early on during the requirements setup. This later resulted in messages during the installation that copied them into .../export/tmp/pip-sb4Nm5-build/numpy/core/lib/... instead of .../numpy/core/lib/.... The library libnpymath.a was simply copied directly back into the temporary directory /export/tmp/pip-... instead of .../numpy/core/lib/libnpymath.a

The build machines had tmp -> /export/tmp. :-)

This fix in pip allows numpy to build without any issues and correctly package the core lib.
After that the scipy builds without any issues because it's able to find the *.ini files and the library.

@zvezdan
Copy link
Contributor Author

zvezdan commented Sep 6, 2015

I forgot to add that it would be really great if this small patch could be released as part of pip-7.1.3 bug-fix release instead of waiting for 8.*. It seems to be critical for people who depend on numpy and scipy and have build systems with symlinks. Thanks!

@dsully
Copy link

dsully commented Sep 9, 2015

+1 for this fix.

@zvezdan
Copy link
Contributor Author

zvezdan commented Sep 23, 2015

Can someone please merge this upstream?
Do you want me to rebase and resolve the conflict in CHANGES.txt first?
If yes, what approach does pip usually use: (a) a clean rebase with a forced push to this branch with PR, or (b) merge of upstream with recorded merge commit.
Looking at the history of pip commits it seems that (a) is preferred and that would be my preference too.
Please, let me know and lets get this change in to help people who build numpy on system with symlinked tmp directory.

@@ -312,7 +312,13 @@ def build_location(self, build_dir):
# package is not available yet so we create a temp directory
# Once run_egg_info will have run, we'll be able
# to fix it via _correct_build_location
self._temp_build_dir = tempfile.mkdtemp('-build', 'pip-')
#
# NOTE: Some systems have /tmp as a symlink which confuses
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the above comment is already a note, it makes little sense to demarkate this paragraph specifically as one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want me to:

  1. remove the comment completely?
  2. remove the marker "NOTE: " only?
  3. merge the comment with the one above on line 314?

Let me know, I can do whatever is preferred here.
It's important to draw attention to the reason for realpath, though, to avoid future regressions. This bug resurfaced multiple times through pip history and we want to avoid that. :-)

@Ivoz
Copy link
Contributor

Ivoz commented Feb 21, 2016

I'm wondering why numpy shouldn't be fixing its custom build system getting confused by such a mundane feature as symlinks, but instead pip should be making allowances for it?

@zvezdan
Copy link
Contributor Author

zvezdan commented Feb 21, 2016

@Ivoz
I completely agree with you that numpy needs to address their custom building approach and make it more robust. I am looking at this only as someone who needs to ensure stable builds of large Python apps that consume numpy as a dependency.

That said, I still believe this needs to be fixed in pip for the following reasons:

  • As described in the comments above this bug had been fixed before and then regressed again (see Pip 1.2.x fails to completely install NumPy (OSX global install) #707). Since this is a regression in pip code, I believe we should fix it.
  • The consumers of numpy (even if they fix numpy build) can still widely use older versions of packages for whatever reason and be affected by this problem. Since problem is so easily fixable in pip, again, it's a good place to apply the fix.
  • Finally, I do believe that returning realpath() in this spot is the right thing to do.

I stumbled upon this issue when I was approached for help by a developer whose app used to work perfectly fine with the older build that used older version of pip and then suddenly exhibited strange breakage in scipy/numpy dependency. To make things more difficult to debug, the build was working perfectly fine on our developer workstations and failing only on automated build machines. It took a while to track down what really happened and the issue #707 provided the clue.

I hope you'll agree with me and accept the patch.

Thanks a lot for reviewing!

I'll rebase from develop and address your code comment now.

@zvezdan
Copy link
Contributor Author

zvezdan commented Mar 5, 2016

Can we merge this fix for regression of #707 now?
It's rebased from develop and passes all the tests.

@srholmes
Copy link

srholmes commented Mar 7, 2016

+1 for this

@dstufft
Copy link
Member

dstufft commented May 18, 2016

Accidentally closed this, reopening. Sorry!

@dstufft dstufft reopened this May 18, 2016
@BrownTruck
Copy link
Contributor

Hello!

As part of an effort to ease the contribution process and adopt a more standard workflow pip has switched to doing development on the master branch. However, this Pull Request was made against the develop branch so it will need to be resubmitted against master. Unfortunately, this pull request does not cleanly merge against the current master branch.

If you do nothing, this Pull Request will be automatically closed by @BrownTruck since it cannot be merged.

If this pull request is still valid, please rebase it against master (or merge master into it) and resubmit it against the master branch, closing and referencing the original Pull Request.

If you choose to rebase/merge and resubmit this Pull Request, here is an example message that you can copy and paste:

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

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

---

*This was migrated from pypa#3079 to reparent it to the ``master``
branch. Please see original pull request for any previous discussion.*
@zvezdan
Copy link
Contributor Author

zvezdan commented May 19, 2016

Re-parented from master and submitted a new pull request: #3701
Closing this one as required.

@zvezdan zvezdan closed this May 19, 2016
dstufft pushed a commit that referenced this pull request May 20, 2016
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 #3079 to reparent it to the ``master``
branch. Please see original pull request for any previous discussion.*
ethankhall pushed a commit to linkedin/pygradle that referenced this pull request Jun 21, 2016
We are using a custom version that fixes the build of numpy until the
upstream project releases our pull request:
pypa/pip#3079

RB=563664
G=python-foundation-reviewers
R=sholsapp
A=sholsapp
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants