igraph, python-igraph: Update to 0.8.3

[mkoeppe]

(from #30611)

Released Oct 8, 2020. ​https://igraph.org/

the previous update was in #27597, where we also disabled blas/lapack inteface; perhaps it can make a comeback here.

This ticket also adds package texttable version 1.6.3, a dependency of python_igraph.

---

source tarballs: see checksums.ini

[dimpase]

source at ​https://github.com/igraph/igraph/releases/download/0.8.3/igraph-0.8.3.tar.gz

[dcoudert]

This version of igraph is also in homebrew ​https://formulae.brew.sh/formula/igraph. I don't think we are currently checking whether graph is a system package or not.

We also need python_igraph (​https://igraph.org/python/), right ?

[dcoudert]

I tried to update to 0.8.3 on macOS 10.15.7. Compilation went well, but I have the following issues:

sapristi:sage dcoudert$ ./sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 9.3.beta1, Release Date: 2020-11-07               │
│ Using Python 3.9.0. Type "help()" for help.                        │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable.     ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
sage: import igraph                                                                                                                 
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-1-73ffca960e68> in <module>
----> 1 import igraph

~/sage/local/lib/python3.9/site-packages/igraph/__init__.py in <module>
     33 # W0401: wildcard import
     34 from igraph._igraph import *
---> 35 from igraph.clustering import *
     36 from igraph.cut import *
     37 from igraph.configuration import Configuration

~/sage/local/lib/python3.9/site-packages/igraph/clustering.py in <module>
     36 from igraph.drawing.colors import ClusterColoringPalette
     37 from igraph.statistics import Histogram
---> 38 from igraph.summary import _get_wrapper_for_width
     39 from igraph.utils import str_to_orientation
     40 

~/sage/local/lib/python3.9/site-packages/igraph/summary.py in <module>
      9 from itertools import islice
     10 from math import ceil
---> 11 from texttable import Texttable
     12 from textwrap import TextWrapper
     13 

ModuleNotFoundError: No module named 'texttable'

and

sage: from sage.features import PythonModule                                                                                        
sage: F = PythonModule("igraph", spkg="python_igraph", url="http://igraph.org")                                                     
sage: F.is_present()                                                                                                                
FeatureTestResult('igraph', False)

I don't know what to do

---

New commits:

​d2f206d

trac #30899: update to 0.8.3

[fbissey]

python-igraph has new dependencies that need to be added. pycairo and texttable

​https://pypi.org/project/texttable/

​https://pypi.org/project/pycairo/

We may be able to do without pycairo (which in turns will require cairo either as a spkg or system package, may be it is already required, that need to be checked).

[slelievre]

Indeed python-igraph used to vendor texttable but this was changed:

​https://github.com/igraph/python-igraph/commit/60194fbb7ff3dbd05c140493e116673834318fc2

Careful, it's texttable, not textable (both exist on PyPI).

​https://pypi.org/project/texttable/

[dimpase]

as far as cairo and pycairo are concerned, we can add them, why not?

[fbissey]

cairo is potentially opening a nest of dependencies, so if skipping it was possible, I think that would be preferable.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​373c82b

trac #30899: add texttable

[dcoudert]

I added texttable and it seems ok now on my side. Not sure I did it the right way...

[mkoeppe]

checksums.ini needs upstream_url (see #30895)

spkg-check.in looks incomplete.

The error handling in spkg-install.in can be removed - the function sdh_pip_install already takes care of it

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​2f8d505

addded upstream_url's

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​63d3718

remove unneeded error handling

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9626cf9

use pkg-config to check for libxml

[dcoudert]

What else should be done if we want to use a local installation of igraph (e.g., homebrew) ?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ccad4b3

added missing quotes

[mkoeppe]

Add system package information in distros/ (see ​https://repology.org/project/igraph/versions) and add spkg-configure.m4

[dimpase]

python_igraph by default vendors libigraph, to avoid it one needs to follow ​https://github.com/igraph/python-igraph#linking-to-an-existing-igraph-installation

But I don't know how this can be done with our sdh_pip_install, which does not accept arguments other than ..

[mkoeppe]

You can use the same method that we use in numpy: Use setup.py bdist_wheel and then sdh_store_and_pip_install_wheel.

[dcoudert]

Unless someone wants to give it a try now, I propose to postpone the use of system package to another ticket.

[dimpase]

Replying to dcoudert:

Unless someone wants to give it a try now, I propose to postpone the use of system package to another ticket.

The tricky part is to take care of comment:20 - I'll write the spkg-configure for igraph once this is done, but 1st things 1st.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​af23430

build wheel and install

[dimpase]

igraph does not build on macOS 10.5 with Xcode 12.

[igraph-0.8.3] /bin/bash ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. -I..   -O3 -DIGRAPH_VERIFY_FINALLY_STACK=0 -I../include -I../include -I../src/CHOLMOD/Include -I../src/CHOLMOD/Include -I../src/AMD/Include -I../src/AMD/Include -I../src/COLAMD/Include -I../src/COLAMD/Include -I../src/SuiteSparse_config -I../src/SuiteSparse_config -DNPARTITION -DNTIMER -DNCAMD -Wall  -I../src/prpack -DPRPACK_IGRAPH_SUPPORT -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -O3 -c -o AMD/Source/libigraph_la-amd_1.lo `test -f 'AMD/Source/amd_1.c' || echo './'`AMD/Source/amd_1.c
[igraph-0.8.3] In file included from CHOLMOD/Supernodal/cholmod_super_numeric.c:80:
[igraph-0.8.3] CHOLMOD/Supernodal/t_cholmod_super_numeric.c:510:17: error: implicit declaration of function 'dsyrk_' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
[igraph-0.8.3]                 BLAS_dsyrk ("L", "N",
[igraph-0.8.3]                 ^
[igraph-0.8.3] ../src/CHOLMOD/Include/cholmod_blas.h:331:2: note: expanded from macro 'BLAS_dsyrk'
[igraph-0.8.3]         BLAS_DSYRK (uplo, trans, &N, &K, alpha, A, &LDA, beta, C, &LDC) ; \
[igraph-0.8.3]         ^
[igraph-0.8.3] ../src/CHOLMOD/Include/cholmod_blas.h:132:20: note: expanded from macro 'BLAS_DSYRK'
[igraph-0.8.3] #define BLAS_DSYRK igraphdsyrk_
[igraph-0.8.3]                    ^
[igraph-0.8.3] ./igraph_lapack_internal.h:86:29: note: expanded from macro 'igraphdsyrk_'
[igraph-0.8.3]     #define igraphdsyrk_    dsyrk_
[igraph-0.8.3]                             ^

no surprise, it's very old code they vendor for no good reason, too. I'll open an issue with upstream. The following fixes the problem

build/pkgs/igraph/spkg-install.in

@@ -4 +4 @@
     exit 1
 fi
 
+export CFLAGS="$CFLAGS -Wno-strict-prototypes -Wno-implicit-function-declaration"
 cd src
 sdh_configure --with-external-blas --with-external-lapack --with-external-glpk
 sdh_make

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​3ff4fd8

build wheel and install

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​7e97772

spkg-configure and distros hints for igraph

[mkoeppe]

+upstream_url=https://github.com/foutaise/texttable/archive/vVERSION.tar.gz

better to use pypi.io URLs

[dimpase]

Replying to mkoeppe:

+upstream_url=https://github.com/foutaise/texttable/archive/vVERSION.tar.gz

better to use pypi.io URLs

I don't know where to get a nice url there. there are links to pypi.org there with ugly hashes.

[fbissey]

It should be of the following form (try it) ​https://pypi.io/packages/source/t/texttable/texttable-VERSION.tar.gz

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​5970390

get texttable tarball from pypi

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​bb1b510

igraph in conda, too

[mkoeppe]

The distros files are missing the extension ".txt"

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​978d9a4

trac #30899: add missing .txt extensions

[dcoudert]

I renamed the files.

I have a doubt for gentoo.txt: on page ​https://repology.org/project/igraph/versions it's written dev-libs/igraph but our file contains only igraph. Should I change to dev-libs/igraph ?

[fbissey]

Replying to dcoudert:

I renamed the files.

I have a doubt for gentoo.txt: on page ​https://repology.org/project/igraph/versions it's written dev-libs/igraph but our file contains only igraph. Should I change to dev-libs/igraph ?

igraph would be fine. dev-libs/igraph would be useful to lift ambiguities if there were several igraph packages across different categories. That being said you should check what was done for other packages. If we have a convention of using the "long" package name you should follow it.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​938d704

trac #30899: correct gentoo.txt and add freebsd.txt

[dcoudert]

the convention is dev-libs/igraph. I also added a file for freebsd ports.

[dimpase]

OK, needs final review?

[fbissey]

python-igraph is on pypi ​https://pypi.org/project/python-igraph/ so we should use it as upstream instead of

upstream_url=https://github.com/igraph/python-igraph/releases/download/VERSION/python-igraph-VERSION.tar.gz

github generated tarballs sometimes have issues.

[fbissey]

I am not sure about using sage-python23 , aren't we phasing that out to use plain python3 or python?

[dimpase]

Replying to fbissey:

I am not sure about using sage-python23 , aren't we phasing that out to use plain python3 or python?

I copied this from numpy's spkg-install. I suppose here should be a ticket that does away with sage-python23 at some point.

[dimpase]

Replying to fbissey:

python-igraph is on pypi ​https://pypi.org/project/python-igraph/ so we should use it as upstream instead of

upstream_url=https://github.com/igraph/python-igraph/releases/download/VERSION/python-igraph-VERSION.tar.gz

github generated tarballs sometimes have issues.

this tarball is not github-generated, it's a manually uploaded one. cf ​https://github.com/igraph/igraph/releases/tag/0.8.3

[fbissey]

Replying to dimpase:

Replying to fbissey:

python-igraph is on pypi ​https://pypi.org/project/python-igraph/ so we should use it as upstream instead of

upstream_url=https://github.com/igraph/python-igraph/releases/download/VERSION/python-igraph-VERSION.tar.gz

github generated tarballs sometimes have issues.

this tarball is not github-generated, it's a manually uploaded one. cf ​https://github.com/igraph/igraph/releases/tag/0.8.3

that's definitely a good thing. I won't insist on pypi.

[dcoudert]

I tried with a homebrew install of igraph and then sage -I python_igraph and it's working well. I don't know for other systems.

[slelievre]

Replying to fbissey:

I am not sure about using sage-python23 , aren't we phasing that out to use plain python3 or python?

Yes, see #30731.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​348569b

trac #30899: use python3 istead of sage-python23

[dimpase]

build/pkgs/python_igraph/spkg-install.in also has sage-python23

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​cf66e4c

trac #30899: missing change

[dimpase]

I don't like these sage-python23 -> python3 changes. I don't see why this python3 is guaranteed to be the correct python.

In fact, no package at the moment uses python3 to run setup.py, while about a dozen packages use sage-python23. I really think until #30731 is done, we should continue using sage-python23. Sorry I didn't check earlier.

[dcoudert]

I don't know how to remove the 2 lasts commits (I'm still at git beginner level...). Otherwise I can push a revert commit.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

[dcoudert]

OK, I was able to remove the last 2 commits (and so revert to sage-python23). I had to do a forced push.

[mkoeppe]

Replying to dimpase:

I don't like these sage-python23 -> python3 changes.

We will switch over in #30371 - and I agree that it is better for uniformity if we don't do this package by package.

I don't see why this python3 is guaranteed to be the correct python.

It is actually guaranteed by our installation.

• When there is a suitable system python3.x, then Sage creates a venv over it and installs a python3 symlink in $SAGE_LOCAL/bin (which is in $PATH and not shadowed by what is in front of it), so python3 works.
• When there is no suitable system python3.x, then Sage builds one and installs a binary in $SAGE_LOCAL/bin, so python3 also works.

(Side note: After #22731/#30013, the above is still true, but with $SAGE_VENV/bin instead of $SAGE_LOCAL/bin.)

[dimpase]

lgtm

[mkoeppe]

Looks good. Given that this is an optional package, we can defer the actual portability tests to the automatic run of the GH Actions when it is merged into a beta release.

[dimpase]

I've opened ​https://github.com/igraph/igraph/issues/1547 in regard of XCode 12 issue (solved with CFLAGS here).

[mkoeppe]

Follow up in #27921, running the libxml2 check via a script package

[mkoeppe]

Volker, the upstream tarball for python_igraph seems to be missing on the mirrors. Note that make download has been repaired - so it should be easy to check if anything is missing