Try out networkx-metis

[OrkoHunter]

• Update NetworkX
  • Update your installed networkx package with https://github.com/networkx/networkx/pull/1595

• Install networkx-metis

  git clone https://github.com/orkohunter/networkx-metis
  git checkout -b test origin/test
  python setup.py install

Start python interpreter

In [1]: import networkx.addons.metis

In [2]: networkx.addons.metis
Out[2]: <module 'networkx.addons.metis' from '/usr/local/lib/python2.7/dist-packages/networkx-metis-1.0-py2.7-linux-x86_64.egg/networkx/addons/metis/__init__.pyc'>

In [3]: from networkx.addons.metis import metis

In [4]: metis
Out[4]: <module 'networkx.addons.metis.metis' from '/usr/local/lib/python2.7/dist-packages/networkx-metis-1.0-py2.7-linux-x86_64.egg/networkx/addons/metis/metis.pyc'>

In [5]: metis.partition
Out[5]: <function networkx.addons.metis.metis.partition>

In [6]: import networkx as nx

In [7]: G = nx.complete_graph(10)

In [8]: metis.partition(G, 2)
Out[8]: (25, [[0, 1, 2, 3, 6], [4, 5, 7, 8, 9]])

[SanketDG]

This works perfectly with python setup.py install. But it fails with exit code 1 for python setup.py develop:

(networkx)➜  networkx-metis git:(test) python setup.py develop
Compiling _metis.pyx because it changed.
Cythonizing _metis.pyx
running develop
running egg_info
creating networkx_metis.egg-info
writing dependency_links to networkx_metis.egg-info/dependency_links.txt
writing requirements to networkx_metis.egg-info/requires.txt
writing networkx_metis.egg-info/PKG-INFO
writing top-level names to networkx_metis.egg-info/top_level.txt
writing namespace_packages to networkx_metis.egg-info/namespace_packages.txt
writing manifest file 'networkx_metis.egg-info/SOURCES.txt'
reading manifest file 'networkx_metis.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'networkx_metis.egg-info/SOURCES.txt'
running build_ext
building 'networkx.addons.metis._metis' extension
creating build
creating build/temp.linux-x86_64-2.7
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -Isrc/GKlib -Isrc/libmetis -I/usr/include/python2.7 -c _metis.c -o build/temp.linux-x86_64-2.7/_metis.o
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/networkx
creating build/lib.linux-x86_64-2.7/networkx/addons
creating build/lib.linux-x86_64-2.7/networkx/addons/metis
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/_metis.o -Lbuild/temp.linux-x86_64-2.7 -lmetis -lgklib -lgklib -lmetis -o build/lib.linux-x86_64-2.7/networkx/addons/metis/_metis.so
/usr/bin/ld: cannot find -lmetis
/usr/bin/ld: cannot find -lgklib
/usr/bin/ld: cannot find -lgklib
/usr/bin/ld: cannot find -lmetis
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

[OrkoHunter]

You probably need python setup.py build first.

[SanketDG]

Yeah thanks.

[OrkoHunter]

Thanks for trying out.

[ysitu]

I am able to install the package as is now (with the networkx>=2.0 requirement removed) and use it with stock NetworkX 1.9.1. It seems that it is unnecessary to have networkx.addons in NetworkX core (but it is still good to have such a placeholder I think).

[OrkoHunter]

If we think about the structure of this repository, it seems everything is falling into correct place of being a normal package. But, I feel that having networkx.addons might be necessary for the future roadmap of other add-ons to come.

[ysitu]

Yes. But now we can remove >=2.0 frominstall_requires`.

[OrkoHunter]

Yeah okay.

[chebee7i]

Hmm...@OrkoHunter why are we using setuptools for the namespace package? Is it for 2/3 compatibility? Reading https://www.python.org/dev/peps/pep-0420/, it doesn't seem like we need to declared_namespace. And also, it says: Namespace packages cannot contain an __init__.py.

[chebee7i]

Ah yes, that PEP was only accepted for 3.3.

So post-PEP420, you don't need to use declare_namespace (from setuptools) or extend_path from pkutil either. But since we want a single codebase that works with 2.x and 3.x, we still need to use one of them.

[OrkoHunter]

Why are we using setuptools for the namespace package? Is it for 2/3 compatibility?

Shouldn't we use setuptools instead of distutils? Didn't get what are you suggesting.

Regarding pep-420 and about Namespace packages cannot contain an __init__.py as much as I understand, the absence of __init__.py must have been forced if the case would have been this NetworkX Core

networkx/
    (modules, packages, release.py, etc)
    addons/
        __init__.py (with the `decalared_namespace`)
        metis/
            (Don't put __init__.py here! - PEP420)

Networkx-Metis

networkx/
    __init__.py (with the `decalared_namespace`)
    addons/
        __init__.py (with the `decalared_namespace`)
        metis/
            metis.py, enums.py, etc.
            (Don't put __init__.py here! - PEP420)

I don't feel this is ever going to be our the situation because making networkx.addons.<add-on> a shared namespace in networkx-core doesn't seem to be a good idea. So, this idea is redundant.

Now we have a common namespace networkx.addons. The main motivation behind what we have now is the system mentioned in http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python. PEP420 is basically the improved version of PEP382 and PEP402. So, you can say we are using an old style of namespace packages. But in that question, you can see namespace packages running with the presence of __init__.py files all over.

[chebee7i]

Ok, but why does networkx-metis have networkx/__init__.py also declaring it as a namespace package? Shouldn't it only be in networkx/addons/__init__.py (for both networkx and networkx-metis)? Naively, I would have thought that networkx/__init__.py should be blank.

[OrkoHunter]

We can think it as the necessity for providing PYTHONPATH the way to go up and find networkx/addons/__init__.py. Without networkx/__init__.py, it won't be able to look inside networkx/addons/. Basically what we always have to do is maintain the same directory structure over all namespace packages (networkx and networkx-metis in this case) and put declared_namespace __init__.py files in places.

[OrkoHunter]

If you try changing the namespace_packages part in setup.py to just ['networkx.addons'], it asks for declaring networkx too.

[chebee7i]

Yes, and the documentation from PEAK, says you need it in all parent directories:

http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages

[OrkoHunter]

Yes. And it's also in the documentation of setuptools over pythonhosted.org

https://pythonhosted.org/setuptools/setuptools.html#namespace-packages

[OrkoHunter]

Can we setup the travis-ci hook now?

[chebee7i]

I am unable to do that, we'll have to wait for one of the owners.

[OrkoHunter]

We have the documentation now. Probably README.md needs update too.