Hi there! Used the Conda option for Python iGraph installation on my 64 bit Intel Mac OS. How can I fix these errors?
Hi @swag_Master, thanks for reporting this! You mean that these errors occur when installing igraph using conda? Or did you specifically run these tests?
I believe the tests are run (and pass) for linux on our CI, but not for macOS, is that correct @tamas?
We run the unit tests on macOS as well. We actually use cibuildwheel to build Python wheels for all supported architectures and Python versions, and each wheel is tested separately on its own environment, so in general it should be okay. If there is an error in the Anaconda distribution, it is something specific to Anaconda.
The particular place that the error points out is a nasty hack in igraph.Graph.Formula() where I (ab)use Python’s own lexer to parse the “graph formulae” that Graph.Formula() needs as an input. I don’t think it’s harmful in the sense that it won’t affect the result / correctness of any other function from igraph. I believe I have also seen this error earlier on macOS with the “plain” system Python but I managed to do something to avoid this. (Unfortunately I can’t remember what). If I were to make a guess now, I would say it’s probably a line ending issue. We need to look into this more thoroughly.
@vtraag Can you test this on your end a bit? I tried installing Anaconda (most recent version, with Python 3.8) on my end, but it gets stuck forever trying to resolve dependencies when installing python-igraph, and I have no idea what goes wrong there.
I can take a closer look tomorrow, but I don’t have a Mac, so I unfortunately cannot test this.
For the problem concerning resolving the environment, perhaps you can try to install it in a clean new environment?
Okay, tried this in a fresh Anaconda installation in a completely clean virtualenv. This is what I got:
❯ conda install python-igraph -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: -
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
Examining conflict for networkx markupsafe appscript glib xlsxwriter jedi ipython pyqt partd zstd alabaster pydocstyle et_xml...
It then gets stuck here for at least an hour where I lost my patience and pressed Ctrl-C (this is even worse than what pipenv does 
). It seems to be related to conda-forge because it works fine with python-igraph from the official default channel, but that one is stuck at 0.7.1.
Output of conda info if that helps:
❯ conda info
active environment : igraph-anaconda-test
active env location : /usr/local/anaconda3/envs/igraph-anaconda-test
shell level : 1
user config file : /Users/tamas/.condarc
populated config files : /Users/tamas/.condarc
conda version : 4.8.3
conda-build version : 3.18.11
python version : 3.8.3.final.0
virtual packages : __osx=10.15.6
base environment : /usr/local/anaconda3 (writable)
channel URLs : https://repo.anaconda.com/pkgs/main/osx-64
https://repo.anaconda.com/pkgs/main/noarch
https://repo.anaconda.com/pkgs/r/osx-64
https://repo.anaconda.com/pkgs/r/noarch
https://conda.anaconda.org/conda-forge/osx-64
https://conda.anaconda.org/conda-forge/noarch
package cache : /usr/local/anaconda3/pkgs
/Users/tamas/.conda/pkgs
envs directories : /usr/local/anaconda3/envs
/Users/tamas/.conda/envs
platform : osx-64
user-agent : conda/4.8.3 requests/2.24.0 CPython/3.8.3 Darwin/19.6.0 OSX/10.15.6
UID:GID : 501:20
netrc file : /Users/tamas/.netrc
offline mode : False
@vtraag it would be great if you could confirm whether it happens on other platforms as well. If it is macOS-specific, I’ll try to investigate further.
To be sure, Anaconda does not work with virtualenv but with conda environments. You might want to try to install a completely clean environment and install python-igraph using
conda create -n test -c conda-forge python=3.8 python-igraph
This creates a new environment called test and works flawlessly on both Linux (Ubuntu) and Windows. You can then activate this environment using conda activate test. Running python -m unittest in the python-igraph source directory then also runs correctly. The tests files are not bundled with the installed package I noticed, neither for the conda package, nor for the pip wheel.
I am actually not sure why these packages are included here, networkx is not a dependency of python-igraph afaik.
I may have used the wrong terminology, but I was using conda environments 
I’ll try again with the command line that you suggested. For what it’s worth, I’m removing the old environment now and it looks like it’s full of stuff that I never asked for but that may be present in my system Python (things like zeromq, msgpack-python and others), so that could be an explanation for why networkx ended up being there.
Some of these packages may be dependencies of other things that are installed when you create a new environment, I’m not sure. But I’m fairly sure that networkx should not be in there by default.
Hopefully this also works correctly on macOS!
@swag_Master Okay, I managed to install the most recent version of python-igraph from conda-forge on my machine, but I could not reproduce the error you saw there. Are you sure you have installed python-igraph from conda-forge and not from the “stock” Anaconda repo (which contains an outdated version of python-igraph)?
You can test it by running python -c "import igraph; print(igraph.__version__)" – it should print 0.8.2 and not 0.7.1 .
I forgot to ask: where do you see this outdated version of python-igraph? I don’t see the python-igraph package at all in the default channels. Can you perhaps report how you can install the 0.7.1 version from the “stock” channel?
To be honest, I don’t know. Initially I typed conda install python-igraph, not knowing that I needed to specify -c conda-forge explicitly, and I somehow ended up with version 0.7.1. Hmmmm. Maybe it was also somehow pre-installed in my system Python?
OK, I think we can then assume that people cannot install the old version 0.7.1 of python-igraph by accident.
Then the question remains: how did the errors reported by @swag_master come about? My guess is that the files he downloaded from somewhere did indeed not have “correct” line-endings.
@tamas, might it be an idea to bundle the tests with the Python package, so that the installed version can be tested somehow? Or did I miss something and are the tests already available within the Python package (i.e. not only from GitHub/source package)?
The unit tests are included in the source package (i.e. the .tar.gz generated by python setup.py sdist) but not in the wheels (which most people install via pip nowadays). This is intentional; 99% of the users won’t need the unit tests, and if they still want them for some reason, they can always run pip download python-igraph --no-deps --no-binary=:all: to get the source package from the CLI.
It might still be useful for users to run tests to verify whether the installed binary version works correctly for them, no? It just adds a few kilobytes to the download (about 240Kb uncompressed, about 40Kb compressed). I don’t think that should be a problem, right?
Is there any particular reason to explicitly not include the unit tests?
I am not fully comfortable with either Python or Anaconda, but perhaps it’s useful to state the exact commands I usually use to set this up, as they always work quickly and without issues for me (on macOS):
conda create -n myenv python=3.7
conda activate myenv
conda install python-igraph -c conda-forge
myenv is the environment name and 3.7 is the requested Python version.