release-engineering / pubtools-pulplib / 186

100%

master: 100%

Pull #53

travis-ci

Make returned futures proxies for cleaner blocking code

This commit makes every future returned by this client into
a proxy future. A proxy future can be used as a future, but
it will also implicitly proxy attribute and method lookups
through to the underlying result of a future. In many cases,
this allows blocking code to be written as if futures are
not used at all.

This is similar in spirit to commit 15eae3692, embracing
implicit over explicit for cleaner code.

Why?
====

APIs in this library are written to return Futures, to enable
aggressively concurrent code. However, there remain many cases
where concurrency isn't possible or desired, so the APIs are
used in a blocking manner.

Currently, the authors of such code are penalized by having to
add many calls to .result(), making the code noisy. This commit
seeks to reduce that noise and make the blocking code more
readable, while still fully supporting non-blocking code styles.

As an example of why both non-blocking and blocking coding styles
should be supported, consider the search_repository API.

Two cases where a task might need to search for repositories are:

- when uploading a productid cert into a repo, we need to find
  related repos for the same product and update repo notes there.
- when adding or removing RPMs in a repo, we need to search for
  corresponding UBI repo(s) in need of repopulation

Both of these cases can occur during a task which needs to
process many other unrelated steps too, which ideally should
be handled concurrently; hence, non-blocking makes sense here.

But another common case is:

- the user has passed a set of repo IDs into a task and we want
  to perform a certain operation on each repo (e.g. publish;
  clear-repo)

In this case, the desired behavior is generally that we want
to fail the task early and not proceed to next steps if any of
the passed repo IDs are incorrect. So, we do explicitly want
to block on repo search completion, by writing code such as:
... (continued)

18 of 18 new or added lines in 4 files covered. (100.0%)

1280 of 1282 relevant lines covered (99.84%)

1.0 hits per line