On Thursday 04 August 2005 15:24, seth vidal wrote: > yes. And it's prone to breaking. > Handing back data structures against known modules is less likely to > fall apart. > > this is why we have APIs. This is why yum isn't invoking rpm as a system > call. It seems you have missed part of my previous mail. Let me reprint it for you: It's not guaranteed to be right, but most of the time it is and the fact that it's a single line is a major advantage. > And it would be a bear to maintain simply so we could be locked down to > that format, forever. No thank you. I don't understand. There is no "format". Do you think "rpm -qa" provides information in a format, and that rpm is a bear to maintain simply so it can be locked down to that format forever? What I'm thinking about: $ yum --script list available package1 package2 ... You really think that format would be hard to maintain? > It's a question of ease of programming. C is unfun to write in and to > deal with all the memory issues. Python is easy to write in and the yum > modules aren't hard to use. Heck we have the yum-utils to show examples > of just this. Let me disagree. It's *not* a question of ease of programming. Shell scripting is not easy programming. It's a different thing. In the command I showed, I've combined generic tools that I know about because I use them everyday. It was possible because the commands were designed with reuse in mind. Programming is not about combining everyday tools. When I do an "import yum", I'm in an unknown world. It's two different worlds. > Seriously, if you think going down the path to program in python in > order to produce a scriptable interface to yum - just write the program > you're after in python using the yum modules. That's what I've been doing, but I've been duplicating so much code from /usr/share/yum-cli that I now think it would be cleaner just just add an option to add scriptability to yum. Anyway, let me hack, produce a patch, and then maybe, just maybe, you'll actually like it. ;-)
