You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As igraph is now a non-optional dependency, would it be possible to remove a lot of the infrastructure involved in switching it on and off?
At present, we run a "no-igraph" CI job but it actually does use igraph, so it's not testing anything. Case in point: using scipy's sparse array for geodesic distance calculation is currently broken, but not tested in navis, so it just breaks in pymaid (which switches off igraph in a different way).
The text was updated successfully, but these errors were encountered:
I fixed the issue in geodesic_matrix with a5d4b72 but your point is still well taken.
We could probably just rip out the alternative networkx-based implementations that exist in some of the functions and nobody would notice. I'm trying to find a reason to keep them but the only thing I can come up with is a future regression in igraph (or an improvement in networkx) that would cause us to favour a networkx-based implementation over igraph. Probably not a strong argument against dropping the code that's currently effectively dead.
As igraph is now a non-optional dependency, would it be possible to remove a lot of the infrastructure involved in switching it on and off?
At present, we run a "no-igraph" CI job but it actually does use igraph, so it's not testing anything. Case in point: using scipy's sparse array for geodesic distance calculation is currently broken, but not tested in navis, so it just breaks in pymaid (which switches off igraph in a different way).
The text was updated successfully, but these errors were encountered: