mnets / pymnet

The original library for analyzing multilayer networks.
https://mnets.github.io/pymnet/
GNU General Public License v3.0
118 stars 24 forks source link

[REVIEW] Error when computing automorphism #29

Closed ClaudMor closed 3 weeks ago

ClaudMor commented 4 weeks ago

Dear authors,

While running the tutorial on automorphisms, I got the error:

import pymnet
net_social = pymnet.MultiplexNetwork(couplings='categorical', fullyInterconnected=False)
net_social["Alice", "Bob", "Friends"] = 1
net_social["Alice", "Carol", "Friends"] = 1
net_social["Bob", "Carol", "Friends"] = 1
net_social["Alice", "Bob", "Married"] = 1

net_transport = pymnet.MultiplexNetwork(couplings='categorical', fullyInterconnected=False)
net_transport["Helsinki", "Turku", "Train"] = 1
net_transport["Helsinki", "Tampere", "Train"] = 1
net_transport["Turku", "Tampere", "Train"] = 1
net_transport["Helsinki", "Turku", "Ferry"] = 1

print(pymnet.get_automorphism_generators(net_social, allowed_aspects=[0]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\claud\anaconda3\envs\pymnet_review\Lib\site-packages\pymnet\isomorphisms\__init__.py", line 197, in get_automorphism_generators
    assert len(automorphism_group_generator_backends) > 0, \
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: No backends for automorphism generators were imported!

I understand that the bliss-blind package is needed. Anyway, I could not find it online (also, it should come installed as a dependency on Windows x64 machines, according to the documentation).

arashbm commented 4 weeks ago

Interesting. The package is definitely available on PyPI and here on GitHub, but since it is a native extension, it is only set to install automatically as a dependency if we have it pre-built for the specific combination of Python abi version, operating system/libc variant and CPU architecture that you are using. Here is a list of environment that we have it built for. I can see that we have a combination for AMD64 on Windows with CPython8 to 12.

I think what's happening here is that the logic we use to detect if we should install it as a dependency is faulty on windows. Here is how the dependency is defined at the moment:

"bliss-bind >= 0.2.0 ; (sys_platform == 'darwin' or ( (platform_machine == 'x86_64' and sys_platform == 'linux') or (platform_machine == 'amd64' and sys_platform == 'win32') )) and python_version >= '3.8'"

Can you please test what are the values that this excerpt prints?

$ python -c "import sys, platform; print(sys.platform, platform.machine())"

Also, while we try to resolve this, you can try pip installing bliss_bind manually and running the test again. If it fails that gives another data point.

$ pip install -U bliss-bind
cloner174 commented 3 weeks ago

Hi! Additionally:

  1. verify that it is installed correctly:
    pip list | grep bliss-bind
  2. check for conflicting packages:
    conda list
  3. use a new environment.
arashbm commented 3 weeks ago

Fix pushed in bac41b4 and will be in the next release. Seems to be correctly downloading bliss-bind as a dependency on x64 Windows GitHub runners.

@ClaudMor Until the next release you can manually install bliss-bind (pip install -U bliss-bind) as a workaround.

ClaudMor commented 3 weeks ago

I confirm that the error above no longer happens after your fix.

@arashbm if it still useful, here's what your command returns:

PS C:\Users\claud> python -c "import sys, platform; print(sys.platform, platform.machine())"
win32 AMD64

I couldn't find the bliss_bind package on PyPi because on the documentation it is listed as bliss_blind (link).

arashbm commented 3 weeks ago

Thanks for verifying. This also confirms that we fixed the correct issue

I couldn't find the bliss_bind package on PyPi because on the documentation it is listed as bliss_blind (link).

Understandable. As far as Python is concerned, both options should point to the same thing. You should be able to pip install the underscore one and it should still work. PyPI normalizes names to the hyphen version and that's what is used in the package name and anywhere we refer to the package.

But since you can't easily import a module with a hyphen in it, in code we used the underscore version to refer to the module offered by that package.

At least that has been the goal. I'll check to make sure if it is consistent.