[ckan-dev] ckanext-dgu loaders depend on ckan

[David Read]

Stefano,

Thanks for pointing this out. I've corrected the ckanext-dgu readme now.

Good to see you making use of the importer code - it's only been used
for various government purposes up until now, so it will be
interesting to see where you go with it with your use cases.

Note, there is also some Google docs importing code in the ckanclient
repo that we should perhaps merge with the ckanext/importer at some
point. Also, ckanext is getting used for a few libraries now, so to
help with separating out dependencies between them, we've been
thinking about moving the importer code out into ckanext-api-importer.

The ckanext-dgu readme alludes to the original intention of the
importers not requiring the ckan code, but actually there are several
places (including the one you mention) where it is nice to import
ckan. For example, finding out the standard package and resource
attributes, the maximum number of characters in a package name, etc.
It's rather like const declarations in C that you want to share
amongst all ckan-related code, to keep them in step.

You could argue that these basic properties could be put into a
ckan-core repo which didn't have any dependencies, making it easy for
a ckanext user to install. But that is not that simple.

I think we should focus on cutting down the ckan code repo, farming
all but the essentials into extensions, remove lots of deps and make
it easy to install for devs like yourself. BTW do you get any issues
installing ckan?

Dave

On 7 March 2011 12:25, Stefano Costa <stefano.costa at okfn.org> wrote:
> Hi all,
> I'm trying to build a loader script for a few Italian datasets. Start at
> http://packages.python.org/ckan/loader_scripts.html
>
> I cloned ckanext-dgu, installed the pip-requirements just to find out
> that I need to do a full install of ckan.
>
> More specifically,
> ckanext/importer/importer.py wants to import
>
>        from ckan.model.license import LicenseRegister
>
> This might have passed unnoticed because tests assume ckan is installed
> ckanext/dgu/tests/ons/test_ons_loader.py
>
>        from ckan import model
>
> The README
> https://bitbucket.org/okfn/ckanext-dgu/src/ea6870866c49/README.txt is
> thus wrong:
>
>> It is simpler to set-up to run the loaders, because they don't require
>> CKAN to be installed::
>
> I think a simpler setup for loaders would help a lot in getting more
> people involved in the creation of new package. I'm wondering if it
> wouldn't be easier to automate around datapkg for the simple case of
> creating new packages?
>
> Ciao,
> steko
>
> --
> Stefano Costa
> Open Knowledge Foundation Italia http://it.okfn.org/
> http://okfn.org/ · http://www.opendefinition.org/
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>