It's clearer when we catch the exact exception that we expect to find. Is it koji.ParameterError?

@ktdreyer Yes, it is...Added.

Btw, ensure_connection could return hub version not checking only API version. Based on that we could use supported options directl in CLI. It is not related to this PR, but maybe makes sense to create separate issue for that?

:thumbsup:

That's an interesting idea. In many of my applications, I avoid calling ensure_connection() because the Koji interactions are read-only and I don't need to authenticate. In those cases ensure_connection() only introduces latency, because it always calls getAPIVersion, and the result is always 1.

Personally I like the "ask forgiveness, not permission" (with exceptions) instead of "look before you leap" (with a version number check) because it is faster and more Pythonic. When we default to the more modern code paths and handle the old paths with Python exceptions, it makes the code easier to read IMHO.

One thing that could help with maintainability would be to add a comment to the except block hinting at how far back we're intending to support:

# Hubs prior to v1.25.0 do not have a "ts" parameter for getLastHostUpdate

...so it's clear to future Koji developers when it's reasonable to drop the legacy exception handling there.

+1 @jcupova can you just add a comment there?

@tkopecek comment added.

Commit ed262fa2 fixes this pull-request