Let's add more granular exceptions when resources do not exist.
Siege has written some client code that screen-scrapes faultStrings
and puts those into more granular exceptions. Here's the list he's
come up with. From
https://obriencj.preoccupied.net/koji-smoky-dingo/kojismokydingo
NoSuchArchive
NoSuchBuild
NoSuchChannel
NoSuchContentGenerator
NoSuchPackage
NoSuchPermission
NoSuchRPM
NoSuchRepo
NoSuchTag
NoSuchTarget
NoSuchTask
NoSuchUser
Since we assign numeric faultCodes sequentially as we add exceptions
to Koji, it makes sense to me that we'd add these to koji in one go so
they are ordered alphabetically.
The one I'm especially interested in is "NoSuchUser" for
https://github.com/ktdreyer/koji-ansible/issues/221
I'm also wondering how long we have to wait to use these error classes
on the hub, after we've shipped them in the main koji/__init__.py.
A long time ago, Koji wrapped most or all strings with a _() method. I
had to research this because I didn't know what this was about.
Turns out it's a convention for doing localization, using gettext.
This blog explains more:
https://danishpraka.sh/2018/09/09/localization-python.html . There's a
Python script helper ("pygettext") for indexing all those _() calls in
a codebase and writing the English strings into a .pot template for
translators to complete.
I think we should remove this _() method for the following reasons:
1. I can't find that we ever had .pot or .po files for Koji's Git
history. We never had localization for Koji, and I don't think it
makes sense to try to do this now, particularly for the CLI.
2. In recent years, we've stopped wrapping new strings with _() as we
introduce them. Now it's an additional hurdle to new contributors:
"what is this thing", and "should I wrap strings or not?" Maybe one
rule is: don't try to do it anywhere but the CLI? But then why is it
used in koji-gc or koji-shadow? git grep "def _(" is also confusing -
why is the same method defined in four different places?
3. In some cases the CLI prints the hub exception's faultString
directly to the console (for example: "koji disable-user" for a user
that does not exist). Those messages will always be unlocalized (a
good thing, since those messages are evolving into part of Koji's RPC
protocol now as 3rd party apps begin to scrape faultString,
https://github.com/ktdreyer/koji-ansible/issues/221)
4. There are just weird tech debt things / code smell things
associated with this, like https://pagure.io/koji/pull-request/1260 or
the fact that we have to write "pragma: no cover" in koji/__init__.py
because it's too hard to test.
Koji's README.md describes the client as thin; let's make it even
thinner and remove the _() method from Koji altogether.
If external plugins or scripts are still calling koji._() or
cli.koji_cli.lib._(), we can make the method raise a
DeprecationWarning.
- Ken
Koji 1.26.1 is out. Another minor update. So, the update should be
straightforward (no db schema changes) and safe for everybody. End-users
(CLI) are encouraged to update too as there are also minor client-side
fixes.
Thanks to everyone who contributed!
You can read the release notes here:
https://docs.pagure.org/koji/release_notes/release_notes_1.26.1/
Highlights:
- #2990 Fixed compatibility with older hubs (CLI channels/hosts info)
- #3017 Regression fix for proton messages (btypes moved from headers to
body)
- #3046 Fixed volume handling for wrapperRPM
- #2964 - fixed building docker images on CentOS 8.3+
- new docs
- 10 issues fixed
You can view the 1.26.1 roadmap at https://pagure.io/koji/roadmap/1.26.1/
<https://pagure.io/koji/roadmap/1.25.1/>
For the current roadmap, see https://pagure.io/koji/roadmap
You can download this and other releases at https://pagure.io/koji/releases
or PyPi.
See you again with major release 1.27 in ~two months!
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat
