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

Fri Jan 25 12:21:02 UTC 2013

Revisiting this issue - now that I am going to be updating the archiver and
qa extensions for 2.0 and I am keen to clean them up to be example
extensions if possible.

For this I want to break the 1.x compatibility and make a clean start for
2.x eg remove all IGenshiFilters etc use the plugins.toolkit try to not
reach into ckan

so the options I see are

a) branch release-v2.x (or whatever) this feels a bit complicated and hacky
but is the easiest in the short term but OI think has long term costs.

b) create a new extension ckanext2-qa, ckanext2-archiver so we get a whole
new namespace.  We could make ckan 2.0 accept both namespaces and it would
maybe make things less confused for ckan 1.x

c) some other solution I don't know yet

Personally I think ckanext2 is my preferred option but we need a definite
decision that we are happy with and can communicate to our users

I'm keen for feedback on this idea from ckan devs and the wider ckan
community dread, ross etc

Toby

On 18 January 2013 15:36, Toby Dacre <toby.okfn at gmail.com> wrote:

>
>
> On 18 January 2013 09:30, Ross Jones <ross at servercode.co.uk> wrote:
>
>> Toby,
>>
>> Do you have any suggestions on the best way to keep the extensions
>> working with 1.x, and do you have objections to branching the current code
>> into a 1.x branch?  There are still a lot of sites on 1.x for whom the
>> upgrade to 2.0 would be very difficult, or at least very time consuming, at
>> least in terms of templating - maybe not immediately, but at some point in
>> the future.
>>
>>
> Ross,
>
> Hi, I agree it is important to keep 1.x extensions running.  We should at
> the minimum branch at a working version.
>
> Personally I'm very much in to maintaining backwards compatibility where
> we can.  Some extensions can support both ckan 1.0 and 2.0 together
> easily.  But for others it is more difficult.
>
> But we should keep the existing stuff working.
>
> I'd really like us to get some good extension writing docs at some point
> but it would require quite a bit of work and some decisions being made.
>
> basically 1.x we need to use genshi templates, 2.0 we can use both but
> genshi is due to die at some point so they should use jinja2 so to support
> both we need both template types.  With this we could postpone killing
> genshi and just keep genshi templates (this may be the best approach)
> switching to template helpers so the extension adds a helper function that
> renders a snippet means we don't need IGenshiStreamFilter which is the main
> problem.
>
> There are more issues with including stuff from ckan outside of
> ckan.plugins that cause problems.  I think we need to look at each
> extension individually.
>
> Hope that helps.  let me know if you need any specific info.  Hope all is
> good with you.  I'm in a bar on a beach in Thailand so can't complain too
> much
>
> Toby
>
> Ross
>>
>> On 18 Jan 2013, at 04:36, Toby Dacre wrote:
>>
>> My thoughts on this is that it would be nice to have extensions that just
>> work and do not need to be updated just because ckan has changed.
>>
>> Once an extension is ckan 2.0 compatible (and correctly written) then it
>> should work for all future versions of ckan. Therefore there would be no
>> need to release a 2.0, 2.1, 2.x of the extension.  This is mainly about
>> using plugins.toolkit as the only method of integration with ckan.  Now
>> that we can call get_action() without a context the last main hurdle has
>> been removed as extensions needed to import ckan.model before this.
>>
>> 2.0 also moves to Jinja2 so it is a good cut off point or else we need
>> multiple templates or keep genshi ones (but it would be nice to remove
>> these in 2.1 or 2.2)
>>
>> Hmm
>>
>> This is all a bit messy.  My main desire with extensions is to isolate
>> them from core as much as possible to allow refactoring without breakage.
>>
>> As a reminder if we need new things added to the toolkit then this is
>> possible if they make sense and we are happy to support them long term.
>> But much of the issue feels is about how extensions are written so for
>> exam[le I don't think they should ever include lib.helpers but the can
>> access any helper functions within their templates for example - again this
>> gives us flexibility that we need to maintain the code and give power to
>> the end user.
>>
>> It would be nice to have better extension writing guidelines at some
>> point.
>>
>> tobes
>>
>>
>> On 17 January 2013 11:29, Sean Hammond <sean.hammond at okfn.org> wrote:
>>
>>> I agree. I think to keep it simple and consistent our recommendation
>>> should just be that extension branches track the CKAN master and release
>>> branches, even though in reality, very new or simple extensions will
>>> probably only have the one master branch (but by the time they have
>>> conditional behaviour like googleanalytics does, we should just
>>> recommend them to use the branches).
>>>
>>> We'll have to change the install instructions in the README file of each
>>> extension, and probably mention it for extension authors in the 'writing
>>> extensions' sphinx docs too.
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/20130125/52e23b91/attachment-0001.html>