libguestfs (previous posts) now has python bindings, for the all too many Pythonistas out there.
Actually, I need some advice. Is the best way to have a module called guestfs
containing a class called guestfs
? Or is there a more natural way to do this in python? [Edit: See comments]
Anyhow, here is what the bindings look like at the moment:
import os import guestfsg = guestfs.guestfs()g = guestfs.GuestFS() # See comments f = open ("test.img", "w") f.truncate (500 * 1024 * 1024) f.close () g.add_drive ("test.img") g.launch () g.wait_ready () g.pvcreate ("/dev/sda") g.vgcreate ("VG", ["/dev/sda"]) g.lvcreate ("LV1", "VG", 200) g.lvcreate ("LV2", "VG", 200) if (g.lvs () != ["/dev/VG/LV1", "/dev/VG/LV2"]): raise "Error: g.lvs() returned incorrect result" g.sync () del g os.unlink ("test.img")
Of course we also have Perl, OCaml, C, C++ and shell script bindings too.
guestfs.GuestFS is more natural I think.
Thanks Nathaniel. I’ll change that before I upload it.
Does a GuestFS normally take multiple images on the filesystem? namely, do you normally call add_drive more than once ever? Or is GuestFS in a way just a wrapper over the file like object that is a single .img file on the filesystem?
If it’s always one, then you might want the code to look like this:
g = GuestFS(‘foo.img’)
with the possible alternatives
g_file = file(‘foo.img’, ‘rwb’)
g = GuestFS(g_file)
g_handle = os.open(‘foo.img’, os.RW)
g = GuestFS(g_handle)
Furthermore, you might consider this:
pvcreate returns a PV instance, that can be passed to vgcreate; that returns a VG instance, that can be used in lvcreate, etc…
then:
some_pv = g.pv(‘/dev/sda1’)
type(some_pv) == PV
loupgaroublond, kind of ..
The Python binding isn’t very natural Python, because it slavishly follows the C API.
It’s possible to make a more natural binding, but not at the same time (a) following changes in the C API, and (b) remaining sane. The reason is that we autogenerate the bindings for multiple languages (C, Perl, OCaml, Python, shell and maybe “documentation” if that counts as a language).
I should add:
This can’t happen. The design of the library prevents us from implementing something like this.
That’s what i figured. This is something that would be in the Python layer only, and not inherent to the library itself. If anything, it would be a wrapper on top of the C-like API that got imported.
Since you’re using strings as identifier, the object would contain a string that it ‘hides’ from the programmer. It’s just a slightly different way to do things that fits a more object oriented model.