Reorganize lib to fit distribution conventions.

[kronosapiens]

Unfortunately, my earlier PR (#53) didn't quite fix the packaging issues.

To solve the problem, I moved the source files into a snappy subdirectory and added an __init__.py to preserve the existing API. The only API change is that command-line invocation requires referencing the snappy.cmd module, as snappy now refers to a package, instead of an individual module.

I have tested the new packaging by building and installing form source and wheels, run the test suites, and tested the command-line invocation.

[martindurant]

I believe you would not need to change the CLI invocation if cmd.py->__main__.py

[kronosapiens]

I will try it and update the PR!

[kronosapiens]

@martindurant Correct! I renamed cmd.py to __main__.py and the original python -m snappy invocation succeeded!

[martindurant]

Will all users of the new structure need to do this?
Could not the __init__.py import everything one might need from the module, so that we don't force a code change on users of snappy?

[kronosapiens]

@martindurant short answer is no, the public API is unchanged.

In this case, the tests expect access to internal snappy variables (_CHUNK_MAX for example) which didn't make sense to include in the API and import in __init__.py. My first approach was to import the internal snappy module so the tests could access those internal variables.

I've updated the PR to import snappy at the top level and access the hidden variables via snappy.snappy. Let me know what you think.

[martindurant]

That's fine with me, so long as the PR is transparent for users.

[kronosapiens]

Agreed; the current API is preserved, assuming users are not attempting to access private variables.

[martindurant]

Anyone with any further comments?

[andrix]

LGTM! 👍

[martindurant]

Thank you @kronosapiens for your work!

[kronosapiens]

My pleasure! Do you know when the new version will be on PyPi?