[ckan-dev] Default CKAN distribution

James Gardner james at 3aims.com
Wed May 18 15:39:17 UTC 2011


Hi Seb,

> My point was rather that we should have the concept of a standard
> useful CKAN install, which is core CKAN + some extensions.  We are
> ending up with a number of extensions that I would consider core to
> everyday use.

Agreed, I'm happy for you to lead on what those should be and then I'll 
implement the ckan packages for them.

> If we did it all with debs then the question would be, would there be
> a package called "ckan-standard" which installed "ckan-core" and
> "ckan-googleanalytics" and so on...?  Or...?

There will be one package called "ckan" representing the install we 
think should be considered standard. It will depend on whatever you 
think is appropriate. Each of the extensions it needs will be packaged 
as python-ckanext-stats, python-ckanext-googleanalytics etc and if 
anyone wants a different combination of extensions they can copy the 
ckan example and create their own package called ckan-sebs-favorites or 
ckan-project-such-and-such, using the existing packaged extensions (and 
any new ones) and the bash helper functions I've already written in 
ckan-common. All nice and easy!

James


> On 18 May 2011 16:22, James Gardner<james at 3aims.com>  wrote:
>> Hi Will,
>>
>> We have a "ckan" debian package we can use for this. As a bit of background
>> I've just refactored the packaging a bit so that there is a new ckan-common
>> package which contains a single file which it installs to
>> /usr/lib/ckan/common.sh which contains helper functions that other CKAN
>> related packages can call. As an example the ckan-dgu package has a postinst
>> script which makes use of a lot of them.
>>
>> https://bitbucket.org/okfn/ckan-debs-public
>>
>> Going forward I'd like to see the ckan package in the repo above install a
>> typical CKAN installation so we can re-work its postinst to the same form as
>> the new ckan-dgu package but to use the dependencies below rather than the
>> ones ckan-dgu uses.
>>
>> At that point a typical ckan installation is as easy as apt-get install so
>> there would be little benefit in a canned image, although we could easily do
>> that too. I'm happy to take on the creation of the ckan package myself when
>> I'm back if it can wait until then? CKAN 1.4 will also be out by then so it
>> makes sense to make a formal packaged release anyway.
>>
>> Cheers,
>>
>> James
>>
>>
>> On 18/05/11 15:34, William Waites wrote:
>>> a canned AWS image and/or VMware image would go very far for
>>> evaluation purposes.
>>>
>>> Cheers,
>>> -w
>>>
>>> * [2011-05-18 15:31:53 +0100] Seb Bacon<seb.bacon at gmail.com>    écrit:
>>>
>>> ] Hi,
>>> ]
>>> ] It strikes me that there are now a number of extensions that are
>>> ] pretty indispensable for a useful site.  For example, the admin
>>> ] extension, the stats extension, the google analytics extension.
>>> ]
>>> ] To make it attractive to people who are evaluating it, we could think
>>> ] about how to assemble a "distribution" nicely.
>>> ]
>>> ] Thoughts?
>>> ]
>>> ] Seb
>>> ]
>>> ] _______________________________________________
>>> ] ckan-dev mailing list
>>> ] ckan-dev at lists.okfn.org
>>> ] http://lists.okfn.org/mailman/listinfo/ckan-dev
>>>
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev





More information about the ckan-dev mailing list