Smooth out archival packaging of courses

[alexander-bauer]

Ideally, courses could be distributed as a single file. That would be a .tar.gz or .zip file, preferably the former, containing the entire course directory. The Course.load() method could be extended to handle these easily using the tarfile module.

A sensible directory structure within the archive might be

.
└── test
    ├── course.yaml
    └── lessons
        ├── basics.yaml
        └── advanced.yaml

The main downside to this is that in order to load the archive, you have to figure out its subdirectory's name. In this case, that is test. It would make it very simple to extract them, though, if they were to be shared. To solve the first issue, we could enforce that test.tar.gz's subdirectory's name is test. That could always be a slugified version of the Lesson title.

[WilCrofter]

Courses will often contain special purpose code.

Does it make sense to package courses as python packages with swirlypy as a dependency? (I have no idea what I mean by "as a dependency.")

[alexander-bauer]

That can be included under questions/ or something of the like. We
also need to work on the code necessary to import those. All of the
heavy lifting is already done, but the trick is importing it safely and
automatically.

On Sat, Jul 12, 2014 at 03:57:47PM -0700, William R Bauer wrote:

Courses will often contain special purpose code. What about that?

---

Reply to this email directly or view it on GitHub:
#10 (comment)

[alexander-bauer]

Whether it makes sense to add swirlypy as a dependency is strongly dependent on how the courses themselves are packaged. If they were distributed via a package manager, then they should certainly require swirlypy's package. I don't expect that to ever happen, though - distro packages are too hard to make for individual courses. I believe courses will mostly be run via a swirlypy tool (currently runcourse.py), and so the dependency is implicit.

[WilCrofter]

I agree.

[alexander-bauer]

All done as of cc7233f.