Re: Road map for rpm-python please ...

On Mon, Nov 24, 2003 at 12:49:24AM -0500, seth vidal wrote:
 
> I'm for it. How about a quick sketch of the bindings as you'd like to
> see them. Your 'vision' as it were. Then we can add our own visions.

Cheers, sorry for the delay busy week :(

Currently my plan of attack is to start slowly, I want to go over the existing
bindings extensively, fixing things up for consistency there.  My next step
would be to probably write a rpmbuild/python binding, really something to sink
my teeth into before any drastic action as it's somewhat orthoganal to the
existing bindings.

The other thing which I have and will continue to do is consult people on there
needs, that's somewhat shaping things in my head.  I'd like to leave rpm-python
as bound within rpm in a pretty good shape. Jeff - what's the release schedule
like for next rpm - FC2, FC3? 

I haven't quite figured out the best course of action to enable me to make the
most of rpm and python, at the moment any releases are bound to legacy and
bound to the release schedules of rpm.  I'm not sure how things will change in
December, but I 

I do get the feeling that tidy up, freeze are pretty much determined.  Then
whether a fork with it's own release cycle or a completely new set of bindings
should be looked at is something I should mull over.  

Some of the things that appeal to me are:

1) Anything rpm(lib) can do so should rpm-python - at the moment that's not
true, but there should be no need to have system/exec calls to rpm within a
python script.  The major headache here is for things like parseSpec, but
that's something I'm going to play with in rpmbuild bindings first attempt

2) rpmbuild bindings, 

3) More pythonesque ways for doing things - some stuff is still very bit
shifting/masking which is great but can be more than a little obtuse. This may
be done by higher level full python objects rather than at the binding level.

4) unit/regresion tests/better docs - as I'm reviewing the existing code base I
want to ensure when anything new is done that I'm not unintentionally missing
anything and that it's pretty easy for anyone to hack on.

> the more pythonic the module, the better.

Indeed.  Also there are all the support libraries which need to be looked at..

This probably isn't so much a vision yet more a plan of attack but hopefull should get me started.

Paul