[pacman-dev] Python 3 bindings for libalpm
Hello people, I have used the code started by Imanol Celaya (at http://github.com/ornitorrincos/pyalpm/) to start my own version of Python bindings for libalpm. It is written for Python 3 using the pacman 3.5 API, with a bit of object-oriented choices, but trying to stay closest to the libalpm API. You can find it at git://projects.archlinux.org/users/remy/pyalpm.git/ It currently implements three classes : DB, Package and Options, and none of them can be instantiated by the user. * DB objects are gotten by pyalpm.get_localdb() or pyalpm.get_syncdb(name), pyalpm.get_syncdbs() functions. * Package objects are gotten by the db.get_pkg(name) or db.get_pkgcache() methods. * Options objects are actually a singleton (pyalpm.options) whose attributes control the various libalpm options. See the example scripts in tests/ to know more about the available interface. You can also use pydoc on the compiled library to have an idea of the available methods. Regards, Rémy.
On Sat, Mar 26, 2011 at 18:23, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Hello people,
I have used the code started by Imanol Celaya to start my own version of Python bindings for libalpm.
Nice! I look forward to this. I think that it could help simplify pkgfile a bit.
On 2011/3/29 Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Sat, Mar 26, 2011 at 18:23, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Hello people,
I have used the code started by Imanol Celaya to start my own version of Python bindings for libalpm.
Nice! I look forward to this. I think that it could help simplify pkgfile a bit.
I'm not sure about that. Actually I think we miss some sort of map/reduce/fold functionality on sync databases: these are intrinsically sequential in their access, and we have no way to treat very large databases (files databases for Archlinux are >100Mb in uncompressed size). Such a map/reduce function would help making one shot queries on the database without storing it in memory. Unfortunately, our database format where package information is possibly split in multiple parts makes it harder to implement. Rémy.
participants (2)
-
Daenyth Blank
-
Rémy Oudompheng