Re: ts.check() and ways of getting unresolved dependencies from a ts
Sean Dilda <[email protected]> Mon, 11 Oct 2004 11:21:33 -0400
| Newsgroups | gmane.linux.redhat.rpm.python |
|---|---|
| Message-ID | <1097508092.11520.14.camel@pel> |
On Mon, 2004-10-11 at 11:05, seth vidal wrote: > We could also have ts.check() return a list of 'tsproblem' objects. > > These objects could have attributes like: > problem.type - sense > problem.need - needname/version/whatever > problem.whatneeds - header object of the package that is > needed/conflicted, what have you > For the most part, I like this idea. Especially with special objects, as opposed to just dictionaries (this is for cosmetic as well as backwards compatibility reasons). This reminds me of how the output of os.stat() was changed in the core python libraries. Originally it returned a tuple. Not it returns an object that acts much like you're describing. But they also made it backwards-compatible by making the new object indexable in the same way the tuple was. I suggest following their lead and have it return a list of these new backwards-compatible objects. I do have one other concern. I haven't looked at rpm-python in a while, so I'm not certain.. but is there a standard way of representing name-epoch-version-release in rpm-python? If so, the new objects should of course follow that. If there isn't a standard way, maybe we should look into coming up with one.