Add igraph dependency

[vtraag]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• 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.

This PR ensures that the C core igraph is identical to the C core that is used by the Python interface. Without it, there could in principle be dependencies of python-igraph that use an incompatible C core. This is especially relevant with the new igraph 1.0 C core release.

Ideally, the C core is also directly used in builds, as discussed in #88. For now, this is a reasonable stopgap.

[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]

@xylar , it would be good to get your take on this, given your previous involvement in #88. I think this added dependency is a reasonable alternative to ensure on incompatible C core can be used. Ideally we would address #88 of course, but as discussed, it might be better to have an upstream implementation of that.

[szhorvat]

Good to keep in mind: Since we have experimental functions, python-igraph is guaranteed to be compatible only with the exact same igraph version that it vendors. This will be a bit cleaner after 1.0, but still, if a python-igraph vendors 1.1.x, it should not be allowed to try to link to either 1.0.x or 1.2.x.

[xylar]

@vtraag , happy to take a look. I'm on vacation but will be back home this weekend.

[vtraag]

Good to keep in mind: Since we have experimental functions, python-igraph is guaranteed to be compatible only with the exact same igraph version that it vendors. This will be a bit cleaner after 1.0, but still, if a python-igraph vendors 1.1.x, it should not be allowed to try to link to either 1.0.x or 1.2.x.

Thanks Szabolcs, that is well understood. We can ensure the version specification is updated for future python interfaces, and limit it to compatible minor releases.

@vtraag , happy to take a look. I'm on vacation but will be back home this weekend.

Thanks!

[xylar]

@vtraag, I'm finally getting a chance to look at this. I don't understand the internals but won't igraph be needed as a host dependency, too? How does python-igraph know not to use its internal igraph and instead to use the shared igraph library?

[xylar]

igraph has a run_exports that knows about its compatibility:
https://github.com/conda-forge/igraph-feedstock/blob/main/recipe/meta.yaml#L18-L19
So we should move this to the host section and this will mean igraph is automatically also included as a run dependency with the appropriate constraint.

[szhorvat]

Another note here: python-igraph 0.10.x/0.11.x will NOT work with arbitrary igraph versions. If simply saying igraph >=0.10,<0.11 makes it possible for people to end up with an older igraph and a newer python-igraph, that WILL mess things up.

The options are:

• Specify a single compatible version of igraph (not a range!) for each specific version of python-igraph
• Stick to static linking for the igraph 0.10.x series (I suggest this)
• Take the risk of people ending up with broken configurations that may crash or produce invalid results.

This will be a little bit cleaner starting with igraph 1.x in that each python-igraph version should be compatible with an entire minor version range of igraph. However, in practice, there is likely not going to be more than one minor version in each series, unless we find a critical bug that needs immediate fixing. So in practice not much changes: each python-igraph version will be compatible with one igraph version.

Still, the intention is to be more rigorous about compatibility with the 1.x series, so I'd recommend using dynamic linking only for the 1.x series.

[xylar]

@szhorvat, the run_exports from igraph itself will prevent this. My suggested approach would be that we restrict which version of igraph is allowed at build time and the version at runtime will be restricted to be newer than or equal to that version, and less that the next minor version (because of the x.x in the run_exports). If that is not correct, we should fix the run_exports in igraph itself.

[xylar]

Specify a single compatible version of igraph (not a range!) for each specific version of python-igraph

We could do this but it would require ignoring the run_exports from igraph, which currently allow newer patch versions of igraph at runtime than were used a build time.

[xylar]

@szhorvat, I believe I have added this in 1bd16f8. I used the version associated with the submodule that is used to vendor igraph in python-igraph 0.11.9.

[xylar]

With help from copilot, I have several suggested changes in c3208b9, which I'm testing in #98. They worked locally on linux64. If they work for other builds, I think we should cherry-pick that commit over here and rerender. If not, I'll try to debug there.

The main thing is that we can clean things up a lot by using the external igraph. We don't need a lot of dependencies, we don't need to make the CMake calls in build.sh and bld.bat, we don't need run_exports anymore, we don't need to vendored igraph license, etc.

[xylar]

It seems Windows' version of pkg-config only finds what it needs if we have a bunch of libraries in the host environment, see 5c3d6cf.

I believe I have things working as we want in #98. If you want to cherry-pick my 2 commits and then rerender here, we should be good to go.

[xylar]

Alternatively, we could merge #98.

[xylar]

@vtraag, have you had any time to look at #98? I remain uncomfortable with this PR but if #98 seems like a step too far, we should chat and see if we can move things forward.