Django Package Thunderdome: Is your package worthy?

Presented by Audrey Roy & Daniel Greenfeld

1. Review criteria

   1. Purpose

      • Name should tell you what it does.
      • Real need and be useful.

   2. Scope

      • Small, narrow focus is better.

   3. Documentation

      • No docs means the package is pre-alpha
      • Doc strings != documentation
      • If there are dependencies, they should be in the docs
      • Installation should be bulletproof

   4. Testing

      • Tests improve reliability
      • Tests make it easy to advance python/django versions
      • Tests make it easier for community submissions

   5. Activity

      • When was the last commit?
      • How frequent are the commits?
      • Are there periodic version updates?

   6. Community

      • Active leaders
      • How many contributors?
      • Proper attribution of authors?

   7. Modularity

      • “Pluggability”
      • Installation should be minimally invasive
      • Do not confuse modularity with over-engineering

   8. Availability on PyPI

      • Actually on PyPI

      • Latest release on PyPI

        • Should not have to go to repo for working version

      • Proper version numbers

   9. VCS/Hosting

      • Great: Github/Bitbucket
      • OK: Launchpad/SourceForge
      • Outdated: Google project hosting
      • Poor: Bespoke

   10. License

       • You need a license
       • Companies prefer BSD or MIT
       • http://opensource.org/licenses/category

2. API creation

   1. django-piston

      • Lost points for docs in a wiki.
      • Hundreds of forks

   2. django-tastypie (2nd place)

   3. django-rest-framework (1st place)

   4. django-xmlrpc * No tests

3. Fundamentals

   1. django-debug-toolbar (1st place)

   2. django-coverage

   3. django-extensions (2nd place)

      • Scope is just too big

   4. Pinax

      • Scope is just too big
      • History is unclear on PyPI

4. Registration

   1. django-registration

      • Popular, un-official mirror with templates.
      • If the original had templates, the fork wouldn’t be needed.

   2. Pinax

   3. django-userena (2nd place)

      • Inaccurate authors file

   4. django-social-auth (1st place)

5. Profiles

   1. django-profiles

   2. django-easy-profiles

      • Not really on PyPI
      • Not really modular or tested

   3. django-userena (2nd place)

   4. idios (1st place)

6. Blogs

   1. biblion
   2. django-mingus
   3. django-basic-apps
   4. django-blog-zinnia (1st place)

6. Tagging

   1. django-taggit (1st place)
   2. django-tagging
   3. django-tagging-ng

7. Database Migrations

   1. South (1st place)

      • no license?

   2. nashvegas (2nd place (no shit?))

      • No tests

8. Honorable Mentions

   1. celery & django-celery
   2. django-haystack with pysolr or whoosh
   3. django-fixture-generator, django-sorting, django-pagination, others but they went too fast.

Note

http://bit.ly/django-thunderdome-2011

9. Beyond

   • run code through PEP8
   • aim for 100% test coverage
   • elegant, clean, explicit ways of doing things

10. Get more users * djangopackages.com (!)