Merge lp:~james-w/python-oops-amqp/new-publisher-api into lp:python-oops-amqp

[James Westby]

Provide the new publisher API.

Hi,

Here's a sketch of how the new publisher API could be provided in
oops_amqp.

I think the name is terrible, so suggestions are welcome.

Thanks,

James

[Robert Collins (lifeless)]

A few thoughts: we decided to whine on all legacy publishers in the
oops codebase, so there is little reason to preserve compat here: when
someone updates they can just move the publisher to the new config. As
such, I'd not change the name.

That should make the patch quite a bit smaller.

[James Westby (james-w)]

Hi Rob,

On Sun, 01 Jul 2012 22:07:21 -0000, Robert Collins <email address hidden> wrote:
> A few thoughts: we decided to whine on all legacy publishers in the
> oops codebase, so there is little reason to preserve compat here: when
> someone updates they can just move the publisher to the new config. As
> such, I'd not change the name.
>
> That should make the patch quite a bit smaller.

Indeed.

The reason I didn't do this was firstly out of principle that API breaks
are bad, but primarily because we use this code from a package, so there
may be other users.

I can still do the compatibility break, but it requires auditing other
users, and perhaps a multi-project lockstep change.

What do you think?

Thanks,

James

[Robert Collins (lifeless)]

Well, this is why I think using python from packages today is a poor
idea. The lack of an ABI makes for great friction between developer
good practices and deployment good practices - and see how the python
community is consolidating around workarounds like buildout and
virtualenv.

That said, package rdepends should let you determine users in our
environment pretty reliable, and its still young-time for the project,
so I think it should be fine, long as we don't mess around and get it
done.

Up to you though.

[lp:~james-w/python-oops-amqp/new-publisher-api]

12. By James Westby on 2013-03-11

Switch to breaking API rather than adding a new Publisher object.

Also update the users of the publish() API in the test-suite to expect
the new behaviour.

13. By James Westby on 2013-03-11

Update the requirements to demand the new API from oops.

14. By James Westby on 2013-03-11

Merge trunk.

[Robert Collins (lifeless)]

So I think you should probably just land this, as time is ticking on the change being harder to do if more people start using oops. I'm not really maintaining it anymore...

Unmerged revisions

14. By James Westby on 2013-03-11

Merge trunk.

13. By James Westby on 2013-03-11

Update the requirements to demand the new API from oops.

12. By James Westby on 2013-03-11

Switch to breaking API rather than adding a new Publisher object.

Also update the users of the publish() API in the test-suite to expect
the new behaviour.

11. By James Westby on 2012-07-01

A sketch of the new publisher API in oops_amqp.

PublisherV2 is a bad name.

=== modified file 'README'
--- README	2012-08-10 01:41:44 +0000
+++ README	2013-03-11 20:26:18 +0000
@@ -86,6 +86,7 @@
 you wrap the fallback publisher so that it only gets invoked if the primary
 method failed::
 
+  >>> from oops.publishers import publish_with_fallback
   >>> fallback_factory = partial(amqp.Connection, host="otherserver:5672",
   ...     userid="guest", password="guest", virtual_host="/", insist=False)
   >>> fallback_publisher = oops_amqp.Publisher(fallback_factory, "oopses", "")

=== modified file 'oops_amqp/__init__.py'
--- oops_amqp/__init__.py	2012-08-10 03:06:16 +0000
+++ oops_amqp/__init__.py	2013-03-11 20:26:18 +0000
@@ -53,14 +53,15 @@
 ---------------------
 
 From time to time your AMQP server may be unavailable. If that happens then
-the Publisher will not assign an oops id - it will return None to signal that
-the publication failed. To prevent losing the OOPS its a good idea to have a 
-fallback publisher - either another AMQP publisher (to a different server) or
-one that spools locally (where you can pick up the OOPSes via rsync or some
-other mechanism. Using the oops standard helper publish_with_fallback will let
-you wrap the fallback publisher so that it only gets invoked if the primary
-method failed::
+the Publisher will not assign an oops id - it will return an empty list
+to signal that the publication failed. To prevent losing the OOPS its a good
+idea to have a fallback publisher - either another AMQP publisher (to a
+different server) or one that spools locally (where you can pick up the OOPSes
+via rsync or some other mechanism. Using the oops standard helper
+publish_with_fallback will let you wrap the fallback publisher so that it only
+gets invoked if the primary method failed::
 
+  >>> from oops.publishers import publish_with_fallback
   >>> fallback_factory = partial(amqp.Connection, host="otherserver:5672",
   ...     userid="guest", password="guest", virtual_host="/", insist=False)
   >>> fallback_publisher = oops_amqp.Publisher(fallback_factory, "oopses", "")

=== modified file 'oops_amqp/tests/test_publisher.py'
--- oops_amqp/tests/test_publisher.py	2012-08-10 01:41:44 +0000
+++ oops_amqp/tests/test_publisher.py	2013-03-11 20:26:18 +0000
@@ -113,7 +113,7 @@
         queue = self.useFixture(QueueFixture(channel, self.getUniqueString))
         publisher = Publisher(self.connection_factory, queue.exchange_name, "")
         oops = {'akey': 42}
-        self.assertNotEqual(None, publisher(oops))
+        self.assertNotEqual([], publisher(oops))
         # The private method use and the restart of rabbit before it gets torn
         # down are bugs in rabbitfixture that will be fixed in a future
         # release.
@@ -124,4 +124,3 @@
             self.rabbit.runner._start()
             queue.channel = self.connection_factory().channel()
         self.assertNotEqual([], publisher(oops))
-

=== modified file 'versions.cfg'
--- versions.cfg	2012-08-10 01:41:44 +0000
+++ versions.cfg	2013-03-11 20:26:18 +0000
@@ -5,6 +5,7 @@
 amqplib = 0.6.1
 bson = 0.3.2
 fixtures = 0.3.6
+distribute = 0.6.24
 iso8601 = 0.1.4
 oops = 0.0.13
 pymongo = 2.1.1