Switch to building with igraph dependency

[xylar]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

fixes #88
closes #97

[xylar]

@conda-forge-admin, please rerender

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

[xylar]

@conda-forge-admin, please rerender

[xylar]

@conda-forge-admin, please rerender

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The use of xz is deprecated. If your package links to liblzma, use the new liblzma-devel package. For XZ's command line utilities (like xz and unxz), use the xz-toolspackage. For the xz-enabled GNU tools (like grep), use xz-gpl-tools. Note: Command line utilities should go in requirements/build.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/18059274125. Examine the logs at this URL for more detail.}

[xylar]

@conda-forge-admin, please rerender

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

[vtraag]

Thanks @xylar! Are you sure that it actually builds against the external dependency on Windows?

I remember from looking at this in igraph/python-igraph#790 that on Windows it would not actually compile against the external library, but still rely on the vendored library. Maybe something changed in the meantime, so that it actually does compile correctly, also on Windows. But to be sure, I would need to go through the setup.py logic to double check.

[xylar]

@vtraag, shoot, I forgot that was still a sticking point. I think you are right that Windows is still using the vendored version, not the shared one.

[xylar]

I won't have time to work on this today. I'll put it on my to-do list for tomorrow.

[vtraag]

I am not 100% sure whether it does, but it would be good to double check indeed. I'll also look into it. I agree that this is a preferable route, and even if igraph/python-igraph#790 does not get merged, I think it makes sense to start linking to igraph instead of relying on the vendored code regardless.

[conda-forge-admin]

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/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ If python is a host requirement, it should be a run requirement.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/18468019582. Examine the logs at this URL for more detail.}

[xylar]

I think Copilot helped me to get this patched up. Have to see if all the tests pass now. Some Win tests are...

[xylar]

@vtraag, I think I have things working finally. Do you care to take another look? I added the ignore_run_exports_from for each of those libraries that we were getting complaints about, and the complaints seem to be gone as expected now.

[vtraag]

Thanks @xylar! I'm not yet 100% convinced myself. I'd prefer to check it on a Windows machine myself, but I need to set it up. The particularly worrisome part is here in the README:

Due to the lack of support of pkg-config on MSVC, it is currently not possible to build against an external library on MSVC.

Can you perhaps advice further @ntamas?

[xylar]

@vtraag, another option is to continue vendoring igraph for windows but not for Unix. That's at least a step in the right direction. We don't seem to have a clear alternative if you're not convinced by my patch.

[vtraag]

Now that we're embarking on this path, I would prefer to make the change to using the external igraph library properly. And I know it is possible to implement it, as I've done it in igraph/python-igraph#790, but those changes were more extensive. It might not be needed to make it so extensive, but I prefer to be 100% sure everything is correctly configured before we release something that creates problems for many users.

[xylar]

Sounds good.

[xylar]

We can put this in draft mode and just use it as a point of reference when the time comes.

[ntamas]

I'm not familar with conda-forge - is there a working instance of pkgconfig within conda-forge itself? If so, you can link to an external igraph simply by passing --use-pkg-config to the setup.py script or by setting the IGRAPH_USE_PKG_CONFIG envvar to 1. This will instruct the setup script to use pkg-config to discover igraph and the required compiler/linker flags instead of using the vendored copy in vendor/source.

[vtraag]

Thanks @ntamas, it is reassuring that you haven't identified any other problems.

I've identified the problem with the transitive dependencies. For some reason, pkg-config --cflags --libs igraph also returns the Libs.private entries, which should normally be included only when using --static. The explicit linking to the private dependencies is not necessary when using dynamic linking. I suspect this is a bug on Windows, but I haven't yet encountered any report of it. Ultimately, this is not really that problematic, as it just unnecessarily links against these dependencies, but it shouldn't do any harm itself.

However, for some reason, I'm unable to build locally on my Windows machine, and it keeps complaining about a missing blas.lib. Again here I'm not yet sure what is happening, since it should link to dynamic libraries (i.e. blas.dll or equivalent), not to static libraries (i.e. blas.lib).

[vtraag]

I've now also figured out the missing blas.lib: apparently it seems necessary to build using the netlib variant. When using that, I'm able to build and run igraph successfully in Python.

[vtraag]

I've also read up on linking to DLLs on Windows, apparently .lib files are not just static libraries, they are also import libraries, which are necessary to link to the DLL. So, also on that front, all seems to be well.

[vtraag]

There is a tangentially related issue on pkg-config here: conda-forge/conda-forge.github.io#1880.

It seems that pkgconf instead of pkg-config returns correct results. This is the output of pkg-config:

-IC:/Users/traagva1/AppData/Local/miniforge3/envs/develop/Library/include/igraph
-IC:/Users/traagva1/AppData/Local/miniforge3/envs/develop/Library/include/libxml2
-LC:/Users/traagva1/AppData/Local/miniforge3/envs/develop/Library/lib
-ligraph -lgmp -lblas -lglpk -llapack -lxml2 -licuuc -liconv -lbcrypt

The output of pkgconf on the other hand is:

-IC:/Users/traagva1/AppData/Local/miniforge3/envs/develop/Library/include/igraph
-IC:/Users/traagva1/AppData/Local/miniforge3/envs/develop/Library/include/libxml2
-LC:/Users/traagva1/AppData/Local/miniforge3/envs/develop/Library/lib
-ligraph

Which is what it should be.

It might be simpler and cleaner to patch setup.py to use pkgconf. Note that pkg-config is no longer maintained and that pkgconf is. Perhaps we can also open an issue for this upstream.

In addition, the library names in igraph.pc on Windows should probably be made to match the actual results. This has also been raised before for other libraries, see for instance conda-forge/libpng-feedstock#26. Given that we do not use static linking in conda, the private names should probably not be a problem anyway, but it might be good to open a separate issue for this in the igraph-feedstock repo.

Let me know what you think @xylar.

[vtraag]

On Linux we are easily able to set an alias for pkgconf so that pkg-config resolves to pkgconf. On Windows I'm not sure, but we can give it a try using Set-Alias: https://learn.microsoft.com/en-us/powershell/scripting/learn/shell/using-aliases?view=powershell-7.5.

[xylar]

@vtraag, sounds promising. I don't know when I'll have time to help out with this again but please give this a try!

[vtraag]

I've just pushed a commit to use pkgconf and pkg-config, which hopefully also builds correctly on Windows. I just noted that I forgot to remove the previous patch. If it does build correctly like this, we should not forget to remove it.

[vtraag]

As far as I'm concerned I'm happy with how it is built now. I've also checked things locally on my Windows machine, and that also all checks out. If you agree @xylar, then let's get this merged.

[xylar]

@conda-forge-admin, please rerender

[xylar]

@vtraag, looks good to me! I'm going to rerender just in case and then set this to automerge.

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[xylar]

I'm going to assume the test failure was one of these rare but persistent flukes.