Merge lp:~james-w/python-oops/refactor-publishing into lp:python-oops
| Status: | Merged |
|---|---|
| Approved by: | Robert Collins on 2012-06-26 |
| Approved revision: | 41 |
| Merged at revision: | 29 |
| Proposed branch: | lp:~james-w/python-oops/refactor-publishing |
| Merge into: | lp:python-oops |
| Diff against target: |
503 lines (+324/-50) 5 files modified
oops/__init__.py (+9/-1) oops/config.py (+62/-38) oops/publishers.py (+72/-1) oops/tests/test_config.py (+43/-5) oops/tests/test_publishers.py (+138/-5) |
| To merge this branch: | bzr merge lp:~james-w/python-oops/refactor-publishing |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Richard Harding (community) | 2012-06-08 | Approve on 2012-06-19 | |
| Robert Collins | 2012-06-21 | Pending | |
|
Review via email:
|
|||
Commit Message
Refactor publication to better support publish_only_new.
Description of the Change
Hi,
Here's a stab at the approach we discussed on IRC, what do you think?
I think that maybe the publish method on Config should still do some looking
at the returned ids so that it can update the report, as the current docstring
says it is useful when there's only one publisher.
The approach taken was to leave things pretty much as they are for current
clients, but allow anyone that wants to allocate ids to have APIs they can use
to do it without losing fallback. Once clients have transitioned to the new
API then some cleanup can be done.
Thanks,
James
| James Westby (james-w) wrote : | # |
| Richard Harding (rharding) wrote : | # |
Couple of nitpicks.
Typo in the comment 'publihers' in two cases there.
The 'only_new' terminology kind of confused me as I was expected it to refer to newly published items, but it seems it's more of a flag to only pass along items not already published. So I wonder if s/only_
For the deprecated paths, should we toss out deprecation warnings and use the normal XXX: policy to file a bug that this needs to get cleaned out?
- 31. By James Westby on 2012-06-19
-
Small fixes from review. Thanks Rick.
- 32. By James Westby on 2012-06-19
-
Add a deprecation warning and XXX. Thanks Rich.
| Robert Collins (lifeless) wrote : | # |
The publish attribute needs more docs - what should it return, what is the protocol for a publisher with it. That will let the PublishToMany docs be smaller and more compact.
The results of .publish and .publishers should be compatible, so it doesn't need to be either or. Just call one then the other (eases migration).
I'm not sure about the 'and it picks one id' bit; that discards data. I'd be a lot happier without it. We can have a trivial publisher to choose a single result, to save folk reimplementing that.
def publish_
def publish_
ret = publisher(report)
if not ret:
return ret
return ret[-1]
return publish_one_id
You might like to extend list instead of composing a list; that would make introspection a little easier, give a default repr thats useful and so on.
Rather than a publish() method, define __call__, as the contract for publishers is that of simple callables, see what oops_amqp does, for instance.
Looking at this, I think we can make it simpler and remove the need for a bunch of tests; if PublishToMany were instead called 'publish_
def publish_
def result(report):
ret = []
for publisher in publishers:
if ret:
return ret
return result
publish_to_many then is just:
def publish_
def result(report):
ret = []
for publisher in publishers:
return ret
return result
What do you think?
- 33. By James Westby on 2012-06-20
-
Improve the docstrings. Thanks Rob.
- 34. By James Westby on 2012-06-20
-
Call both `publisher` and `publishers`.
- 35. By James Westby on 2012-06-20
-
Subclass list rather than compose it. Thanks Rob.
- 36. By James Westby on 2012-06-20
-
Use `__call__` rather than `publish`. Thanks Rob.
- 37. By James Westby on 2012-06-20
-
Use a couple of functions to do publish_to_many and publish_
with_fallback. Thanks Rob. - 38. By James Westby on 2012-06-20
-
Add a converter for old-style publishers.
| James Westby (james-w) wrote : | # |
Hi,
I've made the suggested changes.
Thanks,
James
| Robert Collins (lifeless) wrote : | # |
112 + allocated-or-used for the report. The `publishers` should return any
would read better as 'should each return'
116 + non-True (that is None, 0, False, ''), it indicate s that the
excess ' '
What do you think about not warning in this release? Give folk a chance to update without nags, and then nag later?
+ to return a list of ids. The last id in the returned list
51 + will be assigned to the reports 'id' key. See the publish() method
52 + for more information.
This makes a false claim AFAICT: nothing ensures that that assignment takes place.
The handling of publishers could be delegated to publish_to_many:
def publish(self, report):
publishers = publish_
if self.publisher:
publisher = publish_
else:
publisher = publishers
return publisher(report)
convert_
I think I'd rather see:
convert_
where we have a crisp function and as folk update their dependencies they migrate from publishers to publisher.
This is a little confused about plurals:
190 + When publishing oopses to this publisher they will be in turn published
191 + to all publisher registered to this instance until one of the publishers
192 + reports successful publication, at which point no further publishers
193 + will be tried.
Perhaps:
This publisher will attempt to publish to each of the supplied publishers in turn until one of them successfully publishes the report.
"accumulated list of all lists " is a bit ambiguous (does it mean [[], [], []] or [], for all empty responses. Uhm. Perhaps the problem is that the docs are duplicating the definition of publisher at each place. it might be simpler to say 'this is a publisher, see Config.publish for the calling and return conventions. This publisher delegates to the supplied publishers by calling them all, and aggregates the results.' (Similarly for the first-successful case). What do you think?
TestPublishToMany is missing a corner case (no publishers) for its return value assertions.
Also, test_adds_
test_doesnt_
- 39. By James Westby on 2012-06-26
-
More fixes from review. Thanks Rob.
| James Westby (james-w) wrote : | # |
Done.
> What do you think about not warning in this release? Give folk a chance to
> update without nags, and then nag later?
I'm going to leave the warning as instructed by #launchpad-dev. If you feel strongly
I'll take it out.
> The handling of publishers could be delegated to publish_to_many:
>
> def publish(self, report):
> publishers = publish_
> self.publishers))
> if self.publisher:
> publisher = publish_
> else:
> publisher = publishers
> return publisher(report)
Done, but this changes the behaviour, as nothing puts the id in the report
now, and so old style fallbacks won't work, and neither will any code that
expects to find the id in the report.
Thanks,
James
| Robert Collins (lifeless) wrote : | # |
Ah, we covered this on IRC, but I forgot to mention here.
I was proposing that:
- publish(self, report): assign the last id to the report, for callers convenience.
- publish_
- 40. By James Westby on 2012-06-26
-
Revert to putting ids in the report.
- 41. By James Westby on 2012-06-26
-
Document the putting of the id in to the report.

Hi,
I'm going to ask for a review from any of the reviewers so that I
can move forwards with this.
Thanks,
James