search

conda-forge / python-igraph-feedstock

A conda-smithy repository for python-igraph.
BSD 3-Clause "New" or "Revised" License
4 stars 11 forks source link

Link to 'igraph' package? #88

Open szhorvat opened 2 days ago

szhorvat commented 2 days ago

Comment:

Would it be better at this point if 'python-igraph' just linked to igraph? Otherwise we are missing out on LTO (which makes a noticeable performance difference). It is insufficient to compile with LTO if linking isn't also done with it (not currently the case).

Doing this also guarantees that packages like 'leidenalg' always link to the same 'igraph' version as 'python-igraph'.

xylar commented 2 days ago

In general, it would be much more consistent with conda-forge's overall approach if were linking to igraph, rather than building it here. I would be very much in favor of switching to doing that.

szhorvat commented 2 days ago

I'm sure there was a reason to do so, but I can't recall what, and if it's still valid. Let's wait for a response from @vtraag.

Technically, each 'python-igraph' release is guaranteed to be compatible only with one specific 'igraph' release. This is mostly because of potential changes to experimental functions (which are in practice rare). If we do link to 'igraph', then the maintainer must be careful in managing compatible versions of the two packages, which might be an overhead that @vtraag does not want to deal with.

Another reason to use static linking is bug-for-bug consistency with the PyPI release.

I now switched to linking to C/igraph from python-igraph in MacPorts, and didn't find it to be a burden, but then I do track all changes to igraph closely.

xylar commented 2 days ago

I'll certainly defer to you and @vtraag but I'm happy to help make sure the igraph dependency in igraph-python is managed correctly if we head down that road. conda-forge has a pretty strong preference for shared libraries but I can understand that, even so, there are cases where static linking is just easier.

szhorvat commented 2 days ago

I do support this change. The upcoming python-igraph 0.11.6 (which will be based on C/igraph 0.10.13) would be a good opportunity to make this transition.