/* vim: set sw=2 tw=68 sts=2 et : */ Project Goal: Write Python bindings for Paludis, the other package mangler for Gentoo and related distributions. Project Motivation: The extensive public API offered by Paludis would be useful for far more people if there were more choice in programming language and this is where bindings are necessary. Project Benefits: Exposing the full power of Paludis to such a popular programming language as Python will open endless opportunities for writing both simple and complex tools on top of Paludis. Project Deliverables: Bindings(essential): The goal is to expose all useful (from a Python perspective) public classes to Python, and to allow subclassing in Python of select classes. For example the possibility of declaring a new repository format in Python, which can be then used by Paludis, will be extremely useful. Bindings will be written in C++ utilizing the Boost.Python library. Also, where necessary, the raw Python C API will be used. This has already been discussed with the Paludis developers and although it will introduce an optional dependency on the system package manager (an essential part of the system), it seems to be the sanest choice. The code itself is going to follow all the Paludis requirements, which are widely described on the project page and by the developers when in doubt. The naming scheme of Paludis classes and functions seems to be common for Python too, so there is no need to change that. It is likely all the bindings will be included in a single module. Test cases(essential): Test cases are extremely important for such a project and will be written even before the actual code for a said class or group of them. They will ensure that the code is compatible with the most current version of Paludis and that all the design requirements are met. They will be of course written in Python utilizing the unittest module, which is included in Python 2.1 and later. API Documentation(essential): Python is well-known for the ability to store the documentation in the modules themselves and there is no reason not to take advantage of that. Fortunately adding the documentation to the bindings module with help of the Boost.Python could not be any easier. For generation of external documentation, most probably, epydoc will be used. Demos and tutorial(highly wanted): Practice is the best way of learning so some real examples of how things can be done with the bindings are important. Also the 'Programming with Paludis' tutorial is planned to be extended. Project Schedule: - 6 weeks - Writing the bindings for core classes with API docs and unit tests. - 1 week - Extending the 'Programming with Paludis' tutorial and writing demos. - *event* - After the above are done, the code is planned to be released in the next major Paludis version. - 1 week - Writing the bindings for QA classes with API docs and unit-tests. Updating the tutorial. - 4 weeks - Allowing the subclassing of select classes: Query, Repository and Environment. Updating the tutorial. Proof of Concept: I have already written some bindings code as a proof of concept. While doing so I have become quite familiar with the Boost.Python library and Paludis design patterns and thus I can start coding immediately after the Google Summer of Code begins. The code has been also positively reviewed by the Paludis developers and hence ensures that I am qualified to develop it. Implementation details: Exceptions (paludis_python.hh: register_exception): Paludis C++ exceptions are translated to Python ones with the same name, and with output of backtrace() and message() saved in corresponding string attributes. Validated classes (paludis_python.hh: class_validated): Paludis developers had some hesitations about them when implementing Ruby bindings and eventually decided not to use them at all. I have decided to just make them transparent so everyone is happy: >>> cat = paludis.CategoryNamePart("cat") >>> paludis.QualifiedPackageName(cat, "-badpkgname") (...) paludis.PackageNamePartError: Name '-badpkgname' is not a valid package name part Collection classes (paludis_python.hh: class_collection): They are translated to Python Iterables: (...) >>> pkgdbec = pkgdb.query(match, query_order) >>> for pkg in pkgdbec: print pkg sys-apps/paludis-0.16.2::gentoo sys-apps/paludis-0.18.0::paludis-overlay (...) >>> pkgs = list(pkgdbec) Singleton classes (e.g. environment.cc: EnvironmentMaker): They are translated to classes with get_instance class method as there is nothing more appropriate in Python. Unit tests (e.g. version_spec_TEST.py): They will be very thorough, every constructor, method and operator must be tested with every combination of args that they can take. Also throwing proper exception will be tested. Build system (Makefile.am): The problem with building the module is quite the same as with Ruby bindings. Libtool refuses to make anything that isn't called libfoo.so.x.y.z while Python wants just paludis.so. Moreover paludis.so used for tests must be linked differently as during tests the libs are not yet installed. I am really glad that the Paludis Developers already made the Makefile for Ruby bindings. References: - Boost.Python - http://www.boost.org/libs/python/doc/index.html - Paludis - http://paludis.pioto.org - sample code - http://dev.gentoo.org/~peper/soc/paludis-python/ Personal: I am first year Computer Science student at Warsaw University in Poland. I have been using Gentoo since spring 2005 and became a Gentoo developer in October 2006. The idea for this project arose after I recently fell in love with the simplicity of Python and noticed the lack of bindings for my primary package manager, Paludis. After the project is done I will of course maintain and develop it further and to be honest, I even hope to contribute in other parts of Paludis and become one of its developers.