This is a single class library. Users will most likely to use the MetaFrame class only. So it would be better if we can do that like from metaframe import MetaFrame, instead of current from metaframe.metaframe import MetaFrame.

One way to do this is to define MetaFrame within __init__.py, or just importing it there. But sometimes this causes some unwanted overheads if importing metaframe.MetaFrame is costly.

And, if we put package metadata like __version__, there might be build time dependency problems. metaframe.__init__.py will be imported at the build time. There should be an error since pyspark is not a build time dependency. (I did't tested this. Not 100% sure.)

I think we can try lazy module imports to handle this. It's kind of hacky but I used it somewhere else, and saw some similer approaches.

It should be something like

# __init__.py

def __getattr__(name):
    if name == "Crawler":
        from metaframe.metaframe import MetaFrame
        return MetaFrame

But.. this works only for python>3.7 (see PEP-562)

This PR applies the suggested implementation in #3 and open to discussion.

Now, users can import MetaFrame from the top-level package. Note that this is working only for python>=3.7.

before;

from metaframe.metaframe import MetaFrame

after;

from metaframe import MetaFrame

Closes #3

How should we maintain versions?

I propose not using scm_setuptools here since it brings some amount of coupling with git that we don't need here. I think we can manually maintain versions by hand.

How should we publish new releases?

Let's start with simple before automating releases. We can manually publish a package to pypi.

It would be a useful feature if we allow users to extend MetaFrame with their custom methods. Currently, we are creating a MetaFrame instance instead of a DataFrame. I think changing this to cls(...) should work, but I haven't tested it. Example usage:

class MyDataFrame(MetaFrame):
    def my_method(self):
        ...