[ckan-dev] [RFC] libckan - Python library for APIv3 (Action) and CKAN v2.0.0

Tue Feb 26 08:51:14 UTC 2013

Hi
Daniel,

It's great to see your work on libckan! I have some immediate feedback.

API Design: As you've said, libckan, at the moment, mimics the CKAN API in
syntax and semantics. We attempted to do the same with ckanclient, and it
was perhaps the wrong route to take.

If you define a Package object in libckan, with a field for each key in a
CKAN package dict, then every time the fields of a CKAN package change in a
new version you will have to change that class. Multiply that across all
the model objects and you have code that will be terribly difficult to
maintain. (You'll also have to add new model objects when we add new ones
in CKAN). This also makes supporting different versions of ckan at once
difficult. Ideally, you want one version of libckan to be able to interact
with different sites running different versions of ckan. Basically, it's
all going be less code, and more flexible and maintainable if you just
deals with dicts and using json to dump and load them, like this gist [1].

Less serious, but nice-to-have recommendations.

Coding Style: Can you look at the imports section[2] of CKAN coding
standards? It'd be nice if you can follow that as well.

Metadata: I notice that you have __author__ metadata in most files. At some
point, I hope you'll be pushing this package to cheeseshop and the metadata
in setup.py should probably be preferred over having it in every file.
Version control has this information too.

Thanks again for this work!

[1] https://gist.github.com/seanh/4130567
[2] http://docs.ckan.org/en/ckan-1.8/coding-standards.html#imports

Nigel

On 21 February 2013 21:50, Daniel Graziotin <dgraziotin at task3.cc> wrote:

> Hello everyone,
>
> As I promised, I wrote some code on which I would like to gather your
> feedback.
> The library is tentatively called libckan. It took me a while to think
> about the structure of the library.
> Even though I wanted to stay as much more Object Oriented as possible, I
> finally decided to mimic CKAN API in both syntax and semantics.
> This is because I would like developers to read CKAN documentation and be
> able to almost immediately use libckan.
>
> Using it will be as easy as:
> ---
> import libckan.logic.action.get
> packages = libckan.logic.action.get.package_search(q='test')
> ---
>
> There are differences between CKAN and libckan structure, especially in
> the models (pure Python models).
> Currently, only package_search and package_list actions are implemented. I
> would like to gather some feedback before continuing.
>
> Read the initial documentation here:
> https://libckan.readthedocs.org/en/latest/index.html
> README file: https://github.com/dgraziotin/libckan/blob/master/README.rst
> Get the source code here: https://github.com/dgraziotin/libckan
>
> I look forward to read your comments, suggestions and criticism.
>
> Best Regards,
> --Daniel Graziotin
>
>
>
> _______________________________________________
> 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/20130226/5b3cf4b5/attachment-0001.html>