Trash: Potential projects

Some ideas for people who're interested in contributing, but don't know what to do. You can also refer to the issues list; this is focussed on self-contained projects of some size.

If you start working on one of these projects, please add a note to it so that others know you're working on it, and let us know on the ipython-dev mailing list.

• Write a history browser: As of IPython 0.11, input history (and optionally output history) is stored in an SQLite database. For 0.12, we've written an interface to this that works outside IPython, and a simple script showing how to use it. You could build a much more flexible system to browse history and dump portions of it to files. This could be terminal-based, a Qt GUI or a web interface to go with the HTML Notebook.
• Flexible readline replacement: (suggestion by Fernando on the ipython-user mailing list). The terminal IPython uses the readline library. But this causes a lot of headaches - OS X can't ship GNU readline, a separate solution is needed for Windows, and we have to reimplement functionality from readline for alternative frontends like the Qt console. We'd like a flexible Python equivalent to support advanced features (like searching with Ctrl-R) across these different platforms, and in different Python interpreters (PyPy, IronPython, etc.). Possible starting points are PyReadline, the library we use on Windows, and PyRepl, a readline replacement already used by PyPy.
• Curses/Urwid frontend: You could develop a more powerful terminal interface to IPython, using a library like curses or urwid, and communicating with an IPython kernel. This could well involve working and sharing code with bpython, because collaboration beats competition :-) . See a more detailed discussion from the mailing list. You might also look at http://pypi.python.org/pypi/blessings/ if you would prefer to work with a more pythonic terminal library.
• More comprehensive buildbot system: IPython supports a variety of platforms, with a number of optional dependencies. This means that changes contributed by developers can easily break the test suite in some supported environment that is less commonly used, especially now that we support Python 3. As of January 2012, we have a ShiningPanda workspace running the tests in different Python versions on Linux. However, there are many more configurations we could test, especially Windows systems:
  • Windows (64+32b), OSX, Linux
  • Python 2.6, 2.7, 3.2
  • without setuptools | with distribute | with setuptools proper
  • PySide | PyQt | no qt bindings
  • with/without the following packages:
    • numpy (stable, dev)
    • matplotlib (stable, dev)
    • tornado
    • pyzmq
    • gtk (linux only)

  Enthought's import hook tools may be valuable for testing with different packages importable.

  buildbot or Jenkins are possible Continuous Integration tools.