Architectural issues and remediation paths about graphein HOT 2 CLOSED

Wow, that was a flurry of commits. Thanks for that! Will be going through today.

Ah point taken wrt to imports. I was hoping to keep them as optional dependencies to avoid too much dependence on external libraries at the expense of best practice.

For the nesting, I think this is also a very good point. This was mostly done to organise some similar sounding functions (e.g. feature functions that can operate on nodes or graphs). But I think clever naming conventions (& possible multipledispatch) can help to bring some clarity if we keep them in a higher-level namespace.

from graphein.

Actually, optional imports are not a bad idea too! I have a pattern that is used in pyjanitor: https://github.com/ericmjl/pyjanitor/blob/dev/janitor/chemistry.py. Here, the optional dependencies are kept in a try/except block, and then we raise an informative error message that tells the user how to install those dependencies.

from graphein.