Added setup requirements

[OrkoHunter]

This adds python setup.py and .gitignore

[chebee7i]

Aside: You can use check-manifest to help find these things:

$ check-manifest -v
listing source files under version control: 93 files and directories
building an sdist: UNKNOWN-0.0.0.tar.gz: 91 files and directories
copying source files to a temporary directory
building a clean sdist: UNKNOWN-0.0.0.tar.gz: 91 files and directories
lists of files in version control and sdist do not match!
missing from sdist:
  src/GKlib/sort.cc
  src/libmetis/gklib.cc
suggested MANIFEST.in rules:
  recursive-include src *.cc

After adding the suggestions from @ysitu, it now shows:

listing source files under version control: 93 files and directories
building an sdist: UNKNOWN-0.0.0.tar.gz: 93 files and directories
copying source files to a temporary directory
building a clean sdist: UNKNOWN-0.0.0.tar.gz: 93 files and directories
lists of files in version control and sdist match

Note that the UNKNOWN probably needs fixing too.

[OrkoHunter]

@chebee7i Yes, thank you for that. setup.py and the namespace packaging are yet to be finalized.

[OrkoHunter]

I added the name in setup.py as networkx.addons.metis. I'll send a follow up PR with the minor tweak in networkx core. I think we have always discussed the prototype as

>>> from networkx.addons import metis

But as of this, it's going to be

>>> from networkx.addons.metis import metis

This is because we can't put all the modules into the networkx.addons namespace which in future would raise conflicts with other addons.

[chebee7i]

Is this because of the namespace package? E.g. everything is actually put into networkx/addons/metis/*?

[OrkoHunter]

Yes, virtually.

[chebee7i]

Honestly, I think that import statement will be confusing to users. But perhaps documentation can help.

[OrkoHunter]

Yes that would feel a little confusing for this addon. But, I think it'd more generous to put networkx-metis related stuff inside networkx/addons/metis rather than just networkx/addons. Yes definitely, documentation will help.

[chebee7i]

Just so I'm clear though, if we didn't go with the namespace route, this would not be an issue at all right? Then, users can just do: from networkx.addons import metis.

[OrkoHunter]

Yes. In that case metis would just be a dummy module to import everything from a proper networkx_metis. @chebee7i I think we should step up and use namespace packages. Addons like features take very great use of it. And it's in good culture too. I just found an example for matplotlib. We should resolve the import issue some other way.

[chebee7i]

I think I'd be okay doing that, I just don't really understand what is gained by using the namespace package. If you can explain, that would help me quite a bit. But yes, let's just continue b/c that is an easy decision to change if we do at all.

[chebee7i]

I guess the value is that people can create addons without having to update networkx. Helpful.

[OrkoHunter]

Yes , totally agree with you! And if you consider both the designs too, then the namespace package way looks better than the simple-hackish metis.py inside it.

[OrkoHunter]

For the namespace package to be installed in networkx.addons.metis, don't we need the __init__.py with the one liner in networkx/addons/metis? I think the one in networkx/addons won't suffice.

[ysitu]

Wouldn't your setup.py install an __init__.py?

[OrkoHunter]

Even if we don't have it in this package? I've found examples on namespace packages which only deal with top level eg. zope.interface or matplotlib.basemap. Here we have networkx.addons.metis to install stuff in.

[ysitu]

Maybe this will help: http://stackoverflow.com/questions/8380381/the-way-to-make-namespace-packages-in-python.

[chebee7i]

https://www.python.org/dev/peps/pep-0420/: "Namespace packages cannot contain an __init__.py."

[ysitu]

You need this directory structure:

$ find networkx -name *.py
networkx/__init__.py
networkx/addons/__init__.py
networkx/addons/metis/__init__.py

networkx/__init__.py and networkx/addons/__init__.py each contain just one line:

__import__('pkg_resources').declare_namespace(__name__)

I have the following in my dummy networkx/addons/metis/__init__.py:

def foo():
  return 3.14

Then I can do:

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import networkx.addons.metis
>>> networkx.addons.metis.foo()
3.14

[OrkoHunter]

@ysitu So, the networkx/metis/__init__.py need to be there in the core? Because networkx-metis will probably not install any __init__.py there.

If networkx/metis/__init__.py does not contain

__import__('pkg_resources').declare_namespace(__name__)

how can networkx-metis install it's modules and everything into it?

[OrkoHunter]

Oh I see, this directory structure is for networkx-metis, isn't it?

[chebee7i]

Yes, I think that is correct @OrkoHunter

[SanketDG]

pyenv and pyenv-virtualenv could be helpful, if you want both python2 and python3 support in your projects.

[OrkoHunter]

Pretty much complete, I guess. Changes might be made because of the issue mentioned in #16.