louvain.__version__ returns 'Please install this project with setup.py'

[zoltan-fedor]

I have two CentOS 7 instance, one with Python 3.5 and one with Python 3.6. The performance of louvain-igraph's find_partition method is 3.5x slower on Python 3.6: louvain.find_partition(g, method='Modularity', weight='weight')

So I am trying to figure out what is the difference between these two, and the only thing I find is the difference in how they react to louvain.__version__:

On the good instance:

>>> louvain.__version__
'0.5.3'

On the bad one:

>>> louvain.__version__
'Please install this project with setup.py'

Now in both cases, even when for the 'bad' one, louvain-igraph has been compiled with setup.py.

Are there some known issues with Python 3.6? 3.5x performance degradation is pretty major.

[vtraag]

Thanks, I'll try to look into the differences some time soon.

[zoltan-fedor]

In the meantime I packed up the "good instance"'s louvain module folder into a tar file and moved onto the other CentOS instance and placed it into the project's root (Python3.6) and loaded it directly and now the performance is in level, but the message of 'Please install this project with setup.py' is still there. Very interesting.

The "migrated" louvain module loaded from the Python3.6 project with the right performance figures still showing the version message:

Python 3.6.3 (default, Oct 11 2017, 18:17:37) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from modules import louvain
>>> louvain.__version__
'Please install this project with setup.py'

[vtraag]

I just tested using Anaconda on Ubuntu for both Python 3.5 and 3.6, but I get identical runtimes and identical version numbers. So, I don't think there is some difference between the two Python versions that creates this problem.

It is possible that the version is returning this version "error" instead of the correct version number (0.5.3) because there are some duplicate packages installed. Are the two separate CentOS instances running on two different physical machines? Or is there some shared Python install or something?

[zoltan-fedor]

They are two separate CentOS instances. The module gets installed into a python virtual environment, it reports this error on version both when installed into the python virtual environment from pip or by compiling.

[vtraag]

OK, good to know. Do you also get the same error when not using a python virtual environment?

[zoltan-fedor]

Sorry, I can't try that, as installing igraph behind a proxy would require rewriting it, so it can download c-core.

[vtraag]

I'm not sure I understand, but apparently if the installation needs to download the igraph c core, you need it to connect through a proxy? How does using virtualenv address that issue?

Perhaps it is best to install the c core separately in that case. You can simply download it from the website http://igraph.org/c/ and do the usual ./configure, make and make install. The library should then be found automatically when compiling the python-igraph and the louvain package. This alleviates the need to download the c core when installing, so that you should no longer encounter the problem with your proxy.

[zoltan-fedor]

Sorry, figured out the installation on the OS level (outside of the python virtual environment) and I can report that outside the python virtual environment it correctly reports the version, while inside the virtual env it doesn't.

$ python3.6
Python 3.6.3 (default, Oct 11 2017, 18:17:37) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import louvain
>>> louvain.__version__
'0.5.3'

This makes it look like the issue is somehow related to installing into a python virtual environment. I setup my virtual envs on the following way, which results in the above error message on displaying the version number.

$ python3.6 -mvenv venv1
$ source venv1/bin/activate
(venv1) xxx@x> pip install louvain

[vtraag]

OK, it probably is related to different library paths in the virtual environment or something like that.