Closed regro-cf-autotick-bot closed 1 year ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
Hi! This is the friendly conda-forge automerge bot!
I considered the following status checks when analyzing this PR:
Thus the PR was not passing and not merged.
@vtraag, the windows build failures are a bit beyond me:
RuntimeError: no igraph.pc was found in the installation folder of igraph
I'm not sure what would have changed from the previous working build in January (but maybe CMake version or something like that). I'll leave it up to you unless you're also stumped and need me to investigate.
I also don't understand directly what's wrong with it. igraph.pc
is correctly installed, but it seems that rglob
can't find it for some reason or something. I'm looking into it, will keep you posted.
I haven't been able to find something immediately, so we'll have to keep digging, I'm afraid.
@vtraag, based on my debugging in #70, I think the problem is with the cmake call:
Running CMake:
D:\bld\python-igraph_1688149582514\_build_env\Library\bin\cmake.EXE
-DIGRAPH_USE_INTERNAL_ARPACK=ON
-DIGRAPH_USE_INTERNAL_BLAS=ON
-DIGRAPH_USE_INTERNAL_GLPK=ON
-DIGRAPH_USE_INTERNAL_GMP=ON
-DIGRAPH_USE_INTERNAL_LAPACK=ON
-DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DBUILD_TESTING=OFF
-DCMAKE_INSTALL_PREFIX=D:\bld\python-igraph_1688149582514\work\vendor\install\igraph
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=D:bldpython-igraph_1688149582514_h_envLibrary
-DCMAKE_PROGRAM_PATH=D:bldpython-igraph_1688149582514_build_envbin;D:bldpython-igraph_1688149582514_build_envScripts;D:bldpython-igraph_1688149582514_build_envLibrarybin;D:bldpython-igraph_1688149582514_h_envbin;D:bldpython-igraph_1688149582514_h_envScripts;D:bldpython-igraph_1688149582514_h_envLibrarybin
-GNinja
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_PREFIX_PATH=D:bldpython-igraph_1688149582514_build_env
-DCMAKE_POSITION_INDEPENDENT_CODE=on
-DIGRAPH_USE_INTERNAL_BLAS=0
-DIGRAPH_USE_INTERNAL_LAPACK=0
-DIGRAPH_USE_INTERNAL_ARPACK=1
-DIGRAPH_USE_INTERNAL_GLPK=0
-DIGRAPH_USE_INTERNAL_CXSPARSE=0
-DIGRAPH_USE_INTERNAL_GMP=0
-DBUILD_SHARED_LIBS=off
-DIGRAPH_ENABLE_LTO=1
-DIGRAPH_ENABLE_TLS=1
-DIGRAPH_GRAPHML_SUPPORT=1 ..\..\source\igraph
There are 2 -DCMAKE_INSTALL_PREFIX
flags and the second one probably takes priority:
-DCMAKE_INSTALL_PREFIX=D:\bld\python-igraph_1688149582514\work\vendor\install\igraph
...
-DCMAKE_INSTALL_PREFIX=D:bldpython-igraph_1688149582514_h_envLibrary
The second one probably comes from IGRAPH_CMAKE_EXTRA_ARGS
. It seems like you would have to add your -DCMAKE_INSTALL_PREFIX
flag after you add IGRAPH_CMAKE_EXTRA_ARGS
if you want it to take precedence.
I'm not exactly sure what the preferred fix is here so I'll have to leave that up to you.
I'm pushing on this because it's holding up my ability to release downstream software (mpas_tools
).
Thanks for debugging! Indeed I overlooked that the path was completely off. I'm not sure why that is now different compared to the last time.
Anyway, these paths shouldn't be coded at all in the IGRAPH_CMAKE_EXTRA_ARGS
, because they are set by setup.py
itself. I'm not exactly sure how they got in there, perhaps some legacy attempts at getting stuff to work.
I've now removed the unnecessary Cmake arguments. This seems to work correctly in Windows. I believe it should also work for Linux, so I've also removed the unnecessary arguments there. If the tests pass, we could merge.
We recently fixed a bug where CMAKE_INSTALL_PREFIX
was not set properly in %CMAKE_ARGS%
on windows. It looks like python-igraph uses shlex.split
which has posix=True
as the default and that breaks in windows. posix=False
on windows should fix that.
In principle the path set by conda-forge should also not be used, since it compiles the C core separately to be linked in to create thePython binary. That is, we don't need to install in a specific conda-forge path, but in the path that is used by setup.py
in the Python interface
The current fail on macOS seems to be related to LTO not being supported by the compiler, so we should probably just turn it off. I can't do this now (on the phone) but can probably take a look later this weekend/early next week.
@vtraag, thanks for making headway on this. When you can get to the final steps, that will be great! But despite what I said about needing this for my own code, no pressure. Enjoy your weekend!
Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found some lint.
Here's what I've got...
For recipe:
<two spaces>#<one space>[<expression>]
form. See lines [19, 20]Hi! This is the friendly conda-forge automerge bot!
Commits were made to this PR after the automerge
label was added. For security reasons, I have disabled automerge by removing the automerge
label. Please add the automerge
label again (or ask a maintainer to do so) if you'd like to enable automerge again!
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@vtraag, almost there! One odd error:
======================================================================
FAIL: testHubScore (tests.test_atlas.GraphAtlasTests.testHubScore)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/conda/feedstock_root/build_artifacts/python-igraph_1688238783123/test_tmp/tests/test_atlas.py", line 104, in testHubScore
sc = g.hub_score()
^^^^^^^^^^^^^
igraph._igraph.InternalError: Error at src/linalg/arpack.c:1091: ARPACK error. -- No shifts could be applied during a cycle of the Implicitly restarted Arnoldi iteration. One possibility is to increase the size of NCV relative to NEV
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/conda/feedstock_root/build_artifacts/python-igraph_1688238783123/test_tmp/tests/test_atlas.py", line 106, in testHubScore
self.assertTrue(
AssertionError: False is not true : Hub score calculation threw exception for graph #224: Error at src/linalg/arpack.c:1091: ARPACK error. -- No shifts could be applied during a cycle of the Implicitly restarted Arnoldi iteration. One possibility is to increase the size of NCV relative to NEV
----------------------------------------------------------------------
Given that it only happened for python 3.11 and only for linux, any chance it's a weird transient error?
The answer seems to be, yes! It passed when I reran it. I'm going to merge!
@vtraag, thanks so much for putting time into this, especially on the weekend.
I believe we already excluded this random failing test previously in #53 , but apparently we still missed something.
Anyway, good to see the test now passed and that we can merge. And sure, no problem!
This PR has been triggered in an effort to update libxml2211.
Notes and instructions for merging this PR:
Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.
If this PR was opened in error or needs to be updated please add the
bot-rerun
label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have theconda-forge-admin
add it for you.This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/5020073690, please use this URL for debugging.