[ckan-dev] Recommended practice for supporting both CKAN 1.8 and 2.0 in extensions

[Ian Ward]

On Thu, Jan 31, 2013 at 4:53 AM, David Read
<david.read at hackneyworkshop.com> wrote:
> Ian, thanks for expanding on how it might work sharing code across two
> repositories for an extension. However it seems rather contrived to me
> and I remain unconvinced by these points. Branches exist for exactly
> this sort of challenge and seems to me to be the best way for
> developers to keep track, compare, copy between the two similar
> threads of work.

I'm in agreement as far as CKAN itself.  The thing we disagree about
is whether separate repositories should have matching branches.  I've
made my case and I'll move along now :-)

> Regarding users installing the extensions, I really think we're
> venturing into cloud cuckoo land if we consider the jump from 1.x to
> 2.0 as the only compatibility jump we're going to see. I've managed
> most of the CKAN releases from 1.2 when extensions were introduced,
> and every release there has been at least one extension that needed
> updates due to changes in interfaces. So we need to have a system of
> branching and referencing compatibility, whatever.

This is the important point.  ckanext2 namespace or no, the decision
is what to do when loading an extension against a particular CKAN
version.

I see plugins.toolkit.check_ckan_version() allows testing for a range
of CKAN versions.  So, if I want to support CKAN 1.8 and 2.x from the
same code base, I can just add that check to the parts of my code that
needs it.  That's good enough for me.

Looking more closely it seems there is nothing special about the
ckanext namespace package.  I could put my extension code wherever I
want if I set up the right setuptools entry points, right?

Ian