Design

[OrkoHunter]

Some of the ideas which I have been able to think for networkx-lemon

1. It can't be assured that any function provided by lemon will be able give the desired output and complete exposure to the wrapper functions with the Graph classes defined by NetworkX. So, we'll need to define some wrapper classes explicitly.
2. Sure we can also provide the back-and-forth option for users to interchange the classes from one to another, somewhat like lemon.Graph(G) where G is a nx.Graph() class.
3. We tend to avoid wildcard imports mostly. But at some places, we can use them for providing a cleaner and shorter API, as it is in NetworkX core.
4. In networkx-metis we have an src directory to carry the external source code. But LEMON provides us way more freedom compared to METIS. We can reproduce the source files and (correct me if I'm wrong) we can even change them. In that case, we can change the way we are bundling the external library. Right now src conveys of something embodying "whole" of METIS. For LEMON, we can pick up files from the directory and place it along with the pyx and pxd using it. This will promote the development of the wrapper files as well as the source library. Just a thought.

[ysitu]

Do we need lemon.Graph? Or at the least do we need to expose such a type? I was thinking that the user would simply pass a nx.Graph to lemon.shortest_path, and things would just work.

[OrkoHunter]

I was thinking that the user would simply pass a nx.Graph to lemon.shortest_path, and things would just work.

Yes, that's the plan and we have to make that work. But I think we would not be able to fully access the diverse lemon functionality without actually wrapping the lemon.Graph class. Well, I'm not sure about this, because we are not into the implications yet.

[ysitu]

What functionality will be unavailable if we do not expose lemon.Graph?

[OrkoHunter]

Well.. To be honest it's just that I can't see how a networkx Graph class will work similar to a lemon Graph class and how the functions are going to behave with the nx.Graph class. I haven't really looked into it.

[ysitu]

The usage pattern will be: the user passes in a nx.Graph, you wrap it in a lemon.Graph and invoke LEMON on it.

[OrkoHunter]

I kinda feel that we need to have the LEMON Graph classes wrapped up even if the API would ask the user to input a NetworkX Graph.

Consider this constructor in BellmanFord class.

public:

    BellmanFord(const Digraph& g, const LengthMap& length) : ... { ... }

When we are wrapping it in api_bellman_ford.pxd, I think the arguments will have to come from cimporting the wrapped Digraph class and pass it. We can't pass a NetworkX's DiGraph class' object here, can we?

However, it would need an extra layer of "conversion" from nx Graph class to the LEMON's Graph class.

[ysitu]

I think that you can directly instantiate LEMON's Digraph in Cython, right?

[OrkoHunter]

We still have to do a

cdef extern from "lemon/concepts/digraph.h" namespace "lemon"

right? I can't think of any other way. Please explain if any.

[OrkoHunter]

I think there can't be a better way of instantiation than wrapping the class and `cimport`ing it in the required algorithmic wrapper module.

[ysitu]

That is what I meant. We just use it directly from Cython. You can think of Cython as an alternative syntax for C++.

[OrkoHunter]

Okay great, we'll start with that!