Catapult - A unified accessor for all package manglers

[Necoro]

Hi,

I want to announce a project I work on for some time now: Catapult. This project tries to provide one unified API to all existing and future package manglers (and similar things) for Gentoo.

Background:
If you want to develop an application which uses package managers internals or API to get something done (e.g. PM GUIs, Scripts ...) you a) are bound to a specific programming language (it is hard to program using portage API in something other than Python) and b) need to digg through all the code - and keep up to changes. This perhaps might not be such a big problem if there is only one PM - but now there are several. And if you want your app to work with all, you have to do everything 3times.
Another way would be to parse output - but I personally really dislike this approach, as it is quite error prone and unreliable.

Technique:
Catapult mainly is a defined API. This API should be implemented by providers which map the internal PM-API to the Catapult one. To make things programming language independent, Catapult isn't really a library, but a DBus-service. Each provider offers its service under a defined bus (e.g. org.gentoo.catapult.portage). Thus it can be used from everything that supports DBus.
Additionally, there should be a libcatapult offering:
- adminstrative stuff (like getting dbus-busname; getting default package manager; etc)
- configuration file handling (/etc/portage/*)

Advantages:
- Applications only have to implement the catapult API - everything else is handled there
- DBus bindings exist for a large variety of languages (and it's growing). Using "dbus-send" even shell-skripts can use it (though something more advanced could be useful here).

Disadvantage:
- using dbus is slower than direct acces. But DBus is young and will get more performance in the future

Current status:
There exists a basic API. A provider for portage using this API has been implemented. The libcatapult is very, very limited atm. I'm currently porting the config handling of Portato from Python to C.

What can YOU do:
The API is really basic. And it is heavily influenced by Portato (as this is where I use the portage API). So if you have suggestions - I would really appreciate it .
There currently is only a provider for portage. So at least two more for pkgcore and paludis would be needed . As I'm not using them - I can't write them myself. Also other providers would be imaginable too (e.g. a fast but limited one using eix). The ideal situation would be, that the PMs manage their catapult provider as part of the project

If you want to see, that it works, you can have a look at the development version of Portato, as I'm going to switch there: