Bootstrapping python packages

[benjaoming]

So I see this project is still pretty bare-bones :)

It's worth getting things on the right track from Day 1 because experience proves that things get harder and less prioritized as projects grow.

I have a couple of questions to start out with:

• Should it be py2+3?
• Should dependencies be bundled in as with Kolibri?
• What kind of dependency policy do we otherwise impose (like pure-python etc)

Otherwise, what I'm looking for is:

• Packaging (setup.py)
• CI
• Code coverage
• Docs w/ sphinx-apidocs

The tool we can use is called cookiecutter (the link is for the specific cookie cutter template). It's a good idea to check out the forks of cookiecutter-pypackage because people sometimes come up with cool variations that don't get merged upstream because the maintainer doesn't agree.

[jayoshih]

Thanks for your suggestions! Cookiecutter seems like a great way to start organizing the repo.

In regards to your questions:

• Should it be py2+3? Yes
• Should dependencies be bundled in as with Kolibri? We can probably get away without bundling them
• What kind of dependency policy do we otherwise impose (like pure-python etc)? We'll probably need to flesh this out more

I started putting together a branch with the cookie cutter format here Would something like this be a good starting point?

[aronasorman]

Hi @jayoshih, @benjaoming,

We do have initial apidocs! http://learningequalityricecooker.readthedocs.io/en/latest/py-modindex.html

It's now updated every time we push to the repo.

Should it be py2+3? Yes

I prefer if we support only Py3 -- a lot of recent Linux distributions now bundle python 3 in (Ubuntu, Arch Linux, Fedora etc.), and we don't have a strong need to support older versions. Not to mention that we can take advantage of newer python libraries such as async def

I don't think we also need to be pure python. Especially since we might do a lot of preprocessing before uploading to the cc server (transcoding videos, compressing files etc.), I think runtime speed and features trump compatibility with limited installations.

I think the use case for ricecooker is to be able to install it like this:

pip install ricecooker

I agree with @jayoshih that we have no need to bundle packages, since this is meant to be used with Internet! (at least for now)

Thus, we do need setup.py, and upload this to PyPI eventually.

(cc @rtibbles)

[benjaoming]

@aronasorman @jayoshih super! It's great actually to get rid of the Python 2 burden right from the beginning. Amongst other things, it means being able to do async stuff that might be relevant eventually.

Regarding docs + PyPi packaging, I still think you should @aronasorman have a look at the structures that these cookiecutter templates try to help projects establish from the beginning. It's nice than putting them in the repo one PR at a time.. I can see that @jayoshih has already opened up #6 -- such fastness :)

[benjaoming]

Closing this because the discussion had neatly and efficiently crystallized in #6.