[Yum-devel] *sack.matchPackages()

[seth vidal]

On Mon, 2006-08-28 at 09:05 -0400, Jeremy Katz wrote:
> On Mon, 2006-08-28 at 08:59 -0400, seth vidal wrote:
> > On Mon, 2006-08-28 at 08:56 -0400, Jeremy Katz wrote:
> > > Alternately, what do we gain by having it return both the exact and
> > > globbed matches from the same function?  From an API standpoint, it
> > > almost seems cleaner to have differing functions for each because then
> > > it's a bit more clear what each is doing.
> > 
> > check out cli.py in install and update. It's useful to know how you
> > matched in that situation.
> 
> Yeah, I was glancing through there... but you'd know how you matched if
> you had
>   exact = sack.matchPackages(...)
>   globs = sack.matchGlobbedPackages(...)


We need to be able to allow the caller to sensibly derive what of their
arguments didn't match anything. So we have to return _something_ about
what the match was or was not, either one is enough. From a user
interface standpoint it's nice to be able to tell the user what didn't
match anything, so they can locate errors more simply.

what we're doing that's similar is in repos. we do a check if the string
being passed in has a glob in it. If it does then it gets passed to
'findRepos()' if not then it just gets matched vs a dict. It just makes
it easier to interact with b/c then you don't have to remember which
method to call, or figure out what your own input is first. However,
repos doesn't tell if you nothing matched.

Maybe it'd be better from a user standpoint if we made sure
matchPackages() only takes a single string item to match instead of a
list.

Then the interfaces can know what didn't match anything based on length
of the list they get back.

Yah, That's probably the best way to handle it. We end up having to
offload more of this into the cli.py and friends, though, which to be
fair, is where it probably deserves to be.

-sv