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

Thu Jan 31 15:21:42 UTC 2013

Hi,

Of possible interest to this list, I wrote a blog post on my experience
with CKAN / datahub.io and comparing it to Figshare.

http://insights.exploreyourdata.com/2013/01/31/saving-and-sharing-your-files-for-perpetuity-figshare-or-datahubio/

Feedback welcome!

Clement

--------------------------------------------
Clement Levallois, PhD
Erasmus University Rotterdam
The Netherlands

pro website<http://www.erim.eur.nl/ERIM/People/Person_Details?p_aff_id=4321>
 / personal website <http://www.clementlevallois.net/>

twitter and skype: @seinecle
Discover the NESSHI project: http://www.nesshi.eu

On Thu, Jan 31, 2013 at 4:04 PM, Ian Ward <ian at excess.org> wrote:

> 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
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130131/dccb6e01/attachment-0001.html>