nphilipp commented on the pull-request: `modulepkg.py - Look up modules for packages` that
you are following:
``
This is surely a useful tool, thanks! Perhaps we could move it somewhere where module
creators/maintainers can get at it someday.
* Is it normal that it takes pretty long to complete? (Probably yes.)
* I'm unsure about what the `--filter-branch` option does exactly—does it match
components whose `ref` is reachable in the specified branch? For instance, I get
`flatpak-runtime-f26-20170701152209` as one match for `python modulepkg.py -v
--filter-branch ... wayland`, regardless of if I filter for `f26` or `master`.
* The output isn't labeled correctly and could be formatted better if we want module
creators/maintainers to use it:
* You map `ref` to `branch_or_ref`, but the former is used in `modulemd` and git for
commit hashes, branches or tags.
* Similarly, `module_nvr` uses the RPM terms ("version",
"release"), but modules use "stream" (to signify that there is no
lower or higher) and "version" (this both was changed after the relevant PDC API
was defined, sorry!). You should also use colons as separators between name, stream,
version (see
https://pagure.io/modularity/pull-request/43), the PDC API returns the parts
in `variant_id`, `variant_version` and `variant_release`, respectively, e.g. like this:
# PDC API doesn't match the current terminology. Modules use colons as
separators.
m_dict['module_nsv'] =
"{variant_id}:{variant_version}:{variant_release}".format(m)
…and when displaying it, map `module_nsv` to a string like `module
name:stream:version`.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/6970