[ Broadening the audience to include devel@lists.fedoraproject.org ]

Anybody have thoughts about my question below? some examples of places which will need logic like this to replace PDC usage:

 ODCS
    Resolve a module name:stream to a particular build, and do dependency expansion
 fedmod
   Get the flatpak-runtime modulemd to find what packages aren't in the runtime and need to be bundled
atomic-reactor
   Load the modulemd for particular module builds to get profile information and figure out what to install in a container
 flatpak-module-tools 
   Load modulemd and do dependency expansion to build a container locally
 rpkg
    Load the modulemd  module we are building into a flatpak to find what runtime it is using, and hence the right build target
 
Thanks!
Owen
 

On Mon, May 21, 2018 at 1:29 PM, Owen Taylor <otaylor@redhat.com> wrote:
Querying for module information should be done using the MBS and/or Koji APIs.

Various code that I maintain (in OSBS, fedmod, and random tooling) wants to do module build lookups - different variations of  "look up the modulemd for latest build of a NAME:STREAM[:VERSION]". Variations generally being exactly what "latest" means here.

The code generally already is using Koji and the MBS api is quite limited, so I've chosen to do the lookups via Koji.

 https://fishsoup.net/misc/get-module-builds

Is a test tool that incorporates most of the capability that I needed across my uses. It's distinctly more than a couple of lines of code - I can cut-and-paste it for now, but what's the right long-term home? Is there a simpler way?

My best idea right now is that if the 'base_version' and'status' part of my code was simplified to simply be "tag" and avoid reliance on the tag structure of Fedora, then this might make a reasonable addition to the Koji CLI and API - there are some things that using raw tags for the query makes trickier, but it's probably workable.

Thanks for any input!
Owen