Adding an Avro backend

[ahasha]

This PR will fix #370

I'm pretty sure there are edge cases that I haven't thought through, and there are a number of avro types that are not supported (i.e. ['null', 'error_union', 'bytes', 'enum', 'request', 'error', 'fixed']).

However, I figured it is now complete enough to share and get feedback.

[ahasha]

Uh oh, it looks like the avro package itself is not Python 3 compatible.

E   _pytest.config.ConftestImportFailure: (local('/home/travis/build/blaze/odo/odo/backends/tests/conftest.py'), (<class 'SyntaxError'>, SyntaxError('invalid syntax', ('/home/travis/miniconda/envs/odo/lib/python3.4/site-packages/avro/schema.py', 340, 23, '      except Exception, e:\n')), <traceback object at 0x7f1ba8e62888>))

[cpcloud]

Since this package isn't python 3 compatible, specify it with a conda selector like this:

- avro  # [py27]

[ahasha]

Thanks for the near-instantaneous code review!

[cpcloud]

No, thank you for the PR!

[cpcloud]

any reason not to just make self._uri be self.uri and be a public attribute?

[cpcloud]

same with self._codec and self._schema

[ahasha]

uri, schema, and codec feel like properties that should be immutable. If a user changed them, you would need to refresh any open readers and writers. It feels more natural to expect the user to create a new AVRO object rather than reusing an existing one.

[cpcloud]

ok, no biggie

[kwmsmith]

To make these proper data attributes, could you please define a set callable that simply raises AttributeError? See here:

https://docs.python.org/3/howto/descriptor.html#descriptor-protocol

[ahasha]

I'm pretty sure the property function here achieves what you're describing. Would you like me to add a test verifying it, or refactor it into a more standard method format with the @property decorator? I'll just add the test for now.

[kwmsmith]

@ahasha OK, first iteration done.

[ahasha]

@kwmsmith -- thanks for the code review! I don't have bandwidth to respond to it immediately, but I will make time over the next week or two (hopefully). At any rate, I do plan to get back to this.

[kwmsmith]

Thanks to you for being willing to pick this up again.

[kwmsmith]

@ahasha Thanks for picking this back up -- I'll wait to review / merge this PR until you give me an "all finished".

[majidaldo]

bump

[ahasha]

Hey there. Sorry, but priorities shifted over time and I won't be able to continue work on this PR.

(It would make me happy if someone cared enough to finish it and get it merged, though!)

[ahasha]

Releasing my partial review response from back in October

[majidaldo]

can we conclude this?
what i care about:

• is it using fastavro
• don't care about python 2
• just care about 'record' datatype

i might be able to work on this.