He's not dead, he's resting

New Paludis Query Interface (Part II)

In the first part, I gave an overview of the new Paludis query interface. Now I’ll go into details about the new components and how they can be combined.

Environment::operator[] takes a Selection instance. Currently available selections are:

  • selection::AllVersionsSorted, which is like the old qo_order_by_version.
  • selection::AllVersionsUnsorted, which is like the old qo_whatever (although fetching all versions is no longer necessary if you don’t need them).
  • selection::AllVersionsGroupedBySlot, which is like the old qo_group_by_slot. This one is quite expensive.
  • selection::BestVersionOnly, which is like the old qo_best_version_only, but cheaper.
  • selection::BestVersionInEachSlot, which is like qo_best_version_in_each_slot.
  • selection::RequireExactlyOne, which is like qo_require_exactly_one.
  • selection::SomeArbitraryVersion, which is new.

All of the above take a FilteredGenerator as their single parameter. A FilteredGenerator isn’t something you create by hand, though — it’s the underlying type that you get by combining a Generator with a Filter.

You’ll always need a Generator. Your choices are:

  • generator::All. Matches everything, which is generally slow.
  • generator::Matches(PackageDepSpec). Anything matching the spec.
  • generator::Package(QualifiedPackageName). Anything with that name.
  • generator::Repository(RepositoryName). Anything in the named repository.
  • generator::Category(CategoryNamePart). Anything in the named category.

Generators can be combined to produce a new generator using operator &. In this case, the set intersection of the two generators’ results is used.

Filters are optional. To allow you to pass a Generator straight to a Selection, a Generator can automatically convert to a FilteredGenerator.

A FilteredGenerator can have filters added to it using operator| with the new filter on the right. By way of the automatic conversion, a Generator can be used on the left rather than a FilteredGenerator.

Available filters are:

  • filter::All. Lets everything through. This is more useful for PackageDatabase::fetch_unique_qualified_package_name, which takes a Filter parameter. It’s also used internally to avoid having to special-case a generator with no filter.
  • filter::NotMasked. Doesn’t let masked packages through.
  • filter::InstalledAtRoot(FSEntry). Lets things that are installed at a given root through.
  • filter::SupportsAction<ActionClass>. Lets things through that support the given ActionClass (e.g. InstallAction).

Putting this together, we get these patterns:

env[SomeSelection(SomeGenerator() & AnotherGenerator())]
env[SomeSelection(SomeGenerator() | SomeFilter())]
env[SomeSelection(SomeGenerator() | SomeFilter() | AnotherFilter())]
env[SomeSelection(SomeGenerator() & AnotherGenerator() | SomeFilter())]
env[SomeSelection(SomeGenerator() & AnotherGenerator() | SomeFilter() | AnotherFilter())]

and so on.

In Part III we’ll see how the solving is done.


3 responses to “New Paludis Query Interface (Part II)

  1. Pingback: New Paludis Query Interface « Ciaran McCreesh’s Blag

  2. Pingback: Paludis Ruby Bindings and Template Classes « Ciaran McCreesh’s Blag

  3. Pingback: New Paludis Query Interface (Part III) « Ciaran McCreesh’s Blag

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s