modularity / fedmod

#45 implement repoquery-like commands
Merged by asamalik. Opened by asamalik.
adams-pr  into  master

Download 45.patch

This PR adds multiple commands that will be useful to module developers.

List all modules

Lists all modules available.

$ fedmod list-modules
module1
module2
...

List all modularized packages

Lists all packages that have been modularized. It can optionally list only duplicate packages, and show in which modules every package is.

$ fedmod list-rpms
pkg1
pkg2
...
$ fedmod list-rpms --duplicate-only
pkg2
...
$ fedmod list-rpms --list-modules
pkg1    (module1)
pkg2    (module2, module3)
...

Resolve package dependencies

Resolve package dependencies which is useful for creating new modules. User can also specify modular dependencies.

$ fedmod resolve-deps pkg
pkg2
pkg3
pkg4
...
$ fedmod resolve-deps -m host -m platform pkg
pkg3

Find package in modules

Finds out whether a certain package has been modularized and in which module(s).

$fedmod where-is-package pkg
module1
module2

List packages of a module

Lists all packages in a given module. Can also list full NEVRAs.

$ fedmod module-packages module
pkg1
pkg2
$ fedmod module-packages --full-nevra module 
pkg1-0:2.4.28-3.module_e7ab08d3.x86_64
pkg2-0:4.5.20-1.module_e7ab08d3.x86_64

_load_module_metadata_from_cache would be a clearer name :)

Rather than returning the module list here, how about populating a forward lookup table from module name to ModuleMD?

That will also work properly with the short circuit return above that checks for whether or not the metadata has already been read.

We should switch over to click for real at some point - right now we're using it for the progress bars in the metadata downloader, but I never got around to switching the actual arg parsing over.

Much trailing whitespace this file has :)

Mostly +1 from me, but the current structure of the metadata loading code looks like a bug magnet to me. I'd suggest adding a forward lookup table from module names to modulemd records, and using that in the affected functions.

Then you can just have a single helper function that the existing "load all the metadata" function used for modulemd generation also calls.

The usage docs you have above also need to go somewhere. Perhaps a src/README.md file that we pull into the PyPI package and RPM?

Thanks for the review. What you're proposing sounds reasonable, let me do that.

Now it even feel obvious I should have done it that way before. Thanks for noticing. Fix pushed.

1 new commit added

  • use forward lookup table for modules

2 new commits added

  • use forward lookup table for modules
  • implement repoquery-like commands

Nice, this version looks much cleaner. At some point we should eliminate the duplicated reverse lookup tables, but that can be in a later refactoring patch rather than complicating this one.

That leaves:

  • adding some new tests to the tests directory (they don't need to be comprehensive, but should at least ensure basic usage of each command works - your docs examples would be fine)
  • moving the docs from the PR into a src/README.md file (the rudimentary usage docs at the top of the dev README can also be moved there, and replaced with a relative file reference to [users docs](src/README.md)

1 new commit added

  • add tests for module repoquery

1 new commit added

  • add user docs

I've completed both, the tests and the user documentation.

I will merge this PR as we've agreed on irc.

4 new commits added

  • add user docs
  • add tests for module repoquery
  • use forward lookup table for modules
  • implement repoquery-like commands

rebased onto 904ed921367c1761ec6cb599c4a962eb2ed51e46

Pull-Request has been merged by asamalik
Metadata
ncoghlan
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.