django-pyfs 1.0.3

Django pyfilesystem integration

A Django module which extends pyfilesystem with several methods to make it convenient for web use. Specifically, it extends pyfilesystem with two methods:

fs.get_url(filename, timeout=0)

This will return a externally-usable URL to the resource. If timeout>0, the URL may stop working after that period (in seconds). Details are implementation-dependent. On Amazon S3, this is a secure URL, which is only available for that period. For a static filesystem, the URLs are unsecure and permanent.

fs.expire(filename, seconds, days, expires=True)

This allows us to create temporary objects. Our use-case was that we wanted to generate visualizations to users which were .png images. The lifetime of those images was a single web request, so we set them to expire after a few minutes. Another use case was memoization.

Note that expired files are not automatically removed. To remove them, call expire_objects(). In our system, we had a cron job do this for a while. Celery, manual removals, etc. are all options.

To configure a django-pyfs to use static files, set a parameter in Django settings:

DJFS = {‘type’ : ‘osfs’,

‘directory_root’ : ‘djpyfs/static/djpyfs’, ‘url_root’ : ‘/static/djpyfs’}

Here, directory_root is where the files go. url_root is the URL base of where your web server is configured to serve them from.

To use files on S3, you need boto installed. Then,

DJFS = {‘type’ : ‘s3fs’,

‘bucket’ : ‘my-bucket’, ‘prefix’ : ‘/pyfs/’ }

bucket is your S3 bucket. prefix is optional, and gives a base within that bucket.

To get your filesystem, call:

def get_filesystem(namespace)

Each module should pass a unique namespace. These will typically correspond to subdirectories within the filesystem.

The django-pyfs interface is designed as a generic (non-Django specific) extension to pyfilesystem. However, the specific implementation is very Django-specific.

Good next steps would be to:

• Allow Django storages to act as a back-end for pyfilesystem
• Allow django-pyfs to act as a back-end for Django storages
• Support more types of pyfilesystems (esp. in-memory would be nice)
• General code cleanup, documentation, test cases, etc.
• Add better test support. Django does nice things with resetting DBs to a know state for testing. It’d be nice to do the same here.

State: This code is tested and has worked well in a range of settings, and is currently deployed on edx.org. However, it doesn’t have test cases and similar, so can’t be considered truly production-ready. The expiration functionality, in particular, we are not using right now.