Hi,
I'm developing a project named pylibparted that aims to provide python bindings for parted's library (libparted). This project was accepted in Google's Summer of Code and it's being mentored by Fedora. I already have a snapshot available for testing that can be downloaded from pylibparted.tigris.org. I hope this project can be useful for installers such as anaconda, GLI (Gentoo) and others. If possible, I'd like that some anaconda developer could criticize pylibparted's API, so it can be really useful. :-)
Best,
-- Ulisses
On Fri, Jul 22, 2005 at 03:42:31PM -0300, Ulisses Furquim wrote:
Hi,
I'm developing a project named pylibparted that aims to provide python bindings for parted's library (libparted). This project was accepted in Google's Summer of Code and it's being mentored by Fedora. I already have a snapshot available for testing that can be downloaded from pylibparted.tigris.org. I hope this project can be useful for installers such as anaconda, GLI (Gentoo) and others. If possible, I'd like that some anaconda developer could criticize pylibparted's API, so it can be really useful. :-)
What's wrong with the existing pyparted bindings?
On 7/22/05, Matt Wilson msw@rpath.com wrote:
What's wrong with the existing pyparted bindings?
I tried to use it, but it's confuse and obscure, IMHO. I'm trying to make a clean API, so anyone can use it without having to decipher it first. Besides, there are some functions that doesn't need to be a 1x1 translation of the libparted equivalent, so you can use it in a more python way of coding. :-)
-- Ulisses
On Fri, Jul 22, 2005 at 04:32:08PM -0300, Ulisses Furquim wrote:
On 7/22/05, Matt Wilson msw@rpath.com wrote:
What's wrong with the existing pyparted bindings?
I tried to use it, but it's confuse and obscure, IMHO. I'm trying to make a clean API, so anyone can use it without having to decipher it first. Besides, there are some functions that doesn't need to be a 1x1 translation of the libparted equivalent, so you can use it in a more python way of coding. :-)
Generally:
1) initpylibparted() should raise an exception if initialization cannot be performed (due to /proc/ not being mounted or otherwise). Currently you'll just get an error printed and types that are not safe to use. 2) there are very linux-specific things in plp_probeAllDevices(). This might not be good if you want this to be used on other platforms. In parted we tried to keep the OS-specific stuff isolated.
The libparted API was fairly well documented. It should be easy to use the API documentation and get started with pyparted quickly. It seems that a lot of pylibparted and pyparted are much the same, but pylibparted just adds methods to access data whereas pyparted uses attributes.
For what it's worth: this is the third python binding for parted, I believe.
On 7/22/05, Matt Wilson msw@rpath.com wrote:
Generally:
- initpylibparted() should raise an exception if initialization cannot be performed (due to /proc/ not being mounted or otherwise). Currently you'll just get an error printed and types that are not safe to use.
Ok.
- there are very linux-specific things in plp_probeAllDevices(). This might not be good if you want this to be used on other platforms. In parted we tried to keep the OS-specific stuff isolated.
I can isolate OS-specific stuff in pylibparted as well. Do you see any problems with that?
The libparted API was fairly well documented. It should be easy to use the API documentation and get started with pyparted quickly. It seems that a lot of pylibparted and pyparted are much the same, but pylibparted just adds methods to access data whereas pyparted uses attributes.
Hmm.. I don't think they are much the same. Right now I see the following differences between pyparted and pylibparted:
- pylibparted has a cleaner way of creating objects - pylibparted uses methods to access objects' data - pylibparted has more of libparted's functions implemented - pylibparted has some functions in different objects than the libparted API says (why? because I thought it was better for actually doing OO programming with pylibparted) - pyparted doesn't have a way to probe all devices (you have to use a static method of PedDevice to actually create a PedDevice object for your device!) - with pylibparted you don't iterate through lists with a *_next_* method, because pylibparted returns a list where a list should be returned - pylibparted isn't as stable as pyparted and there are some objects (classes) that need to be implemented
IMHO, although Andrew put a nice effort into making libparted as OO as possible, there are some points where the implementation of the python bindings have to be different than the C implementation.
Best,
-- Ulisses
PS: I thought pylibparted was the second python binding for parted, but I guess I was wrong.. :-)
On Fri, Jul 22, 2005 at 07:09:10PM -0300, Ulisses Furquim wrote:
PS: I thought pylibparted was the second python binding for parted, but I guess I was wrong.. :-)
Actually, there are 4 now. First was my pyparted. Then Kiichiro Naka did a parted wrapper in 2001 for Mongoose (their installer based on Anaconda). Then Eric Gillespie did one at Progeny in 2002: (http://archive.progeny.com/progeny/python-parted/). Now there's yours...
On Fri, Jul 22, 2005 at 07:09:10PM -0300, Ulisses Furquim wrote:
Hmm.. I don't think they are much the same. Right now I see the following differences between pyparted and pylibparted:
- pylibparted has a cleaner way of creating objects
Changing the constructors around is pretty. I changed it around several times before it landed the way it is now. Adding an interface that is more palatable to you, while retaining a compatibility interface for the people who use the interface as-is would be an option.
- pylibparted uses methods to access objects' data
I'm not convinced that it's a big win for libpyparted. It's more typing...
- pylibparted has more of libparted's functions implemented
True - I never had a need to implement timers.
- pylibparted has some functions in different objects than the
libparted API says (why? because I thought it was better for actually doing OO programming with pylibparted)
I think this is actually a drawback that could confuse users familiar with the C API.
- pyparted doesn't have a way to probe all devices (you have to use
a static method of PedDevice to actually create a PedDevice object for your device!)
We always implemented this in application-specific code, since many users of pyparted have their own hardware detection code that handles cases that ped_device_probe_all() misses.
- with pylibparted you don't iterate through lists with a *_next_*
method, because pylibparted returns a list where a list should be returned
When pyparted was written, python 1.5.2 was young. This was before iterators. I'd be happy to see someone implement list access through iterators in pyparted, while keeping the _next interfaces for backward compatibility.
Cheers,
Matt
On 7/22/05, Matt Wilson msw@rpath.com wrote:
On Fri, Jul 22, 2005 at 07:09:10PM -0300, Ulisses Furquim wrote:
- pylibparted has a cleaner way of creating objects
Changing the constructors around is pretty. I changed it around several times before it landed the way it is now. Adding an interface that is more palatable to you, while retaining a compatibility interface for the people who use the interface as-is would be an option.
I'm not sure I understood what you meant.. Do you mean pylibparted should have PedDevice.get() and PedDisk.new(), for example?
- pylibparted has some functions in different objects than the
libparted API says (why? because I thought it was better for actually doing OO programming with pylibparted)
I think this is actually a drawback that could confuse users familiar with the C API.
I don't think this can confuse users familiar with the C API. pyparted already changes the location of some functions. pylibparted only improves on that. :-)
- pyparted doesn't have a way to probe all devices (you have to use
a static method of PedDevice to actually create a PedDevice object for your device!)
We always implemented this in application-specific code, since many users of pyparted have their own hardware detection code that handles cases that ped_device_probe_all() misses.
Ok, so users can always use their own hardware detection code and do pylibparted.PedDevice(devicepath) to create a PedDevice object for each device they found.
- with pylibparted you don't iterate through lists with a *_next_*
method, because pylibparted returns a list where a list should be returned
When pyparted was written, python 1.5.2 was young. This was before iterators. I'd be happy to see someone implement list access through iterators in pyparted, while keeping the _next interfaces for backward compatibility.
Ok. I'll implement those iterators in pylibparted. :-)
Best regards,
-- Ulisses
On Tue, Jul 26, 2005 at 10:33:45PM -0300, Ulisses Furquim wrote:
Changing the constructors around is pretty. I changed it around
I'm not sure I understood what you meant.. Do you mean pylibparted should have PedDevice.get() and PedDisk.new(), for example?
I meant that we could change the constructors in pyparted around easily.
We always implemented this in application-specific code, since many users of pyparted have their own hardware detection code that handles cases that ped_device_probe_all() misses.
Ok, so users can always use their own hardware detection code and do pylibparted.PedDevice(devicepath) to create a PedDevice object for each device they found.
True, but it may just be that the C binding isn't the right place to have probing code.
Ok. I'll implement those iterators in pylibparted. :-)
My point is that I don't understand why a totally new project is needed. There are already _lots_ of users of pyparted. Many distros are using it just by basing installer on anaconda. There's other software that's using pyparted as well. I have yet to be convinced that we _really_ need a 4th parted python binding.
On Fri, 2005-07-22 at 15:42 -0300, Ulisses Furquim wrote:
Hi,
I'm developing a project named pylibparted that aims to provide python bindings for parted's library (libparted). This project was accepted in Google's Summer of Code and it's being mentored by Fedora. I already have a snapshot available for testing that can be downloaded from pylibparted.tigris.org. I hope this project can be useful for installers such as anaconda, GLI (Gentoo) and others. If possible, I'd like that some anaconda developer could criticize pylibparted's API, so it can be really useful. :-)
Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: ./pylibparted.so: undefined symbol: ped_disk_commit_from_fd
Please ensure builds against rawhide:
[pauln@enki lib.linux-i686-2.4]$ rpm -q parted parted-1.6.23-2.i386 [pauln@enki lib.linux-i686-2.4]$ rpm -q parted-devel parted-devel-1.6.23-2.i386
Paul
On Fri, Jul 22, 2005 at 03:00:43PM -0400, Paul Nasrat wrote:
Please ensure builds against rawhide:
[pauln@enki lib.linux-i686-2.4]$ rpm -q parted parted-1.6.23-2.i386 [pauln@enki lib.linux-i686-2.4]$ rpm -q parted-devel parted-devel-1.6.23-2.i386
I looked at the tarball when it was first accepted as a SOC project. I seem to remember it needing a parted patch...
On Fri, 2005-07-22 at 15:11 -0400, Matt Wilson wrote:
On Fri, Jul 22, 2005 at 03:00:43PM -0400, Paul Nasrat wrote:
Please ensure builds against rawhide:
[pauln@enki lib.linux-i686-2.4]$ rpm -q parted parted-1.6.23-2.i386 [pauln@enki lib.linux-i686-2.4]$ rpm -q parted-devel parted-devel-1.6.23-2.i386
I looked at the tarball when it was first accepted as a SOC project. I seem to remember it needing a parted patch...
If this is true Ulisses please file a bug against parted with patch and reasoning. Chris can you look over and review/add to rawhide and push upstream as necessary when it's filed.
Paul
On 7/22/05, Paul Nasrat pnasrat@redhat.com wrote:
On Fri, 2005-07-22 at 15:11 -0400, Matt Wilson wrote:
On Fri, Jul 22, 2005 at 03:00:43PM -0400, Paul Nasrat wrote:
Please ensure builds against rawhide:
[pauln@enki lib.linux-i686-2.4]$ rpm -q parted parted-1.6.23-2.i386 [pauln@enki lib.linux-i686-2.4]$ rpm -q parted-devel parted-devel-1.6.23-2.i386
I looked at the tarball when it was first accepted as a SOC project. I seem to remember it needing a parted patch...
If this is true Ulisses please file a bug against parted with patch and reasoning. Chris can you look over and review/add to rawhide and push upstream as necessary when it's filed.
I don't think that will be necessary. That is one of my experimental patches. It tries to dump a pedisk object into a file, that can be imported later and committed to disks. But it's far from complete, so I'll get rid of that code.
-- Ulisses
I looked at the tarball when it was first accepted as a SOC project. I seem to remember it needing a parted patch...
If this is true Ulisses please file a bug against parted with patch and reasoning. Chris can you look over and review/add to rawhide and push upstream as necessary when it's filed.
Sure, I can take a look at any parted patches that may be needed.
Upstream is pretty crazy right now.
- Chris
On 7/22/05, Paul Nasrat pnasrat@redhat.com wrote:
Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: ./pylibparted.so: undefined symbol: ped_disk_commit_from_fd
Please ensure builds against rawhide:
[pauln@enki lib.linux-i686-2.4]$ rpm -q parted parted-1.6.23-2.i386 [pauln@enki lib.linux-i686-2.4]$ rpm -q parted-devel parted-devel-1.6.23-2.i386
I got rid of my experimental code and I _guess_ it builds against rawhide now. I haven't tested it on rawhide because I didn't set up a box with rawhide, but it builds against an up to date FC4 system. If you don't mind, can you compile-test and import-test it on rawhide, please? I made a new tarball of it that you can download (pylibparted-0.6.1) or you can update your svn working copy.
Best,
-- Ulisses
anaconda-devel@lists.stg.fedoraproject.org