[ckan-discuss] CZ-CKAN: QA plugin, Celery issues

Tue Jun 5 12:54:56 BST 2012

Dne Út 5. června 2012 11.23:06, Sean Hammond napsal(a):
> > Oh, now that expains lots... Sometimes I just do not see...
> 
> I think these commands are quite complicated and easy to mess up, so I'm
> not surprised that this happened. Anyway, it's easy to clean up, I just
> deleted the existing ckanext-archiver and ckanext-qa source code
> directories (both containing ckanext-archiver's source) from your
> virtual environment, and then reinstalled both extensions with the right
> commands. Any files installed into your virtualenv by previous install
> commands should have been overwritten by this. At first glance it seems
> to be working now, but let me know if you find any problems. Enjoy!

Thank you very much!

> > Would be great if it all was just system packages, let the package
> > manager do what it is good in... But since the okfn servers setup is a
> > bit non-standard, I see little hope for that...
> 
> Well, one advantage of using Python virtual environments and pip is that
> it's cross-platform, you don't have to build one package for Debian,
> another for RedHat, another for OS X, etc. But I agree that they're very
> fiddly.
> 
> There is already a Debian package for CKAN, but the problem is a little
> more difficult than that, because we need a way of managing multiple
> CKAN websites each with their own configuration, themes, extensions,
> etc. Right now if we had only one copy of the CKAN source code on our
> server (installed via the Debian package) and we upgraded it, then all
> the CKAN websites running on the server would get upgraded to a new
> version of CKAN, and likely they would all break at once, as the themes and
> extensions they're each using would not be compatible with the new
> version of CKAN or would themselves require upgrading. That's why we
> have one copy of the CKAN source code for each website running on the
> server, each of them managed using virtualenv, pip, git, etc. and we
> upgrade the sites one by one.
> 
> What we're planning right now is a better way of managing things using
> the Debian package, so that we could have just one copy of the source
> code and upgrade it and all the different sites running off it would
> just keep working. This means we'd need to upgrade the extensions and
> themes at the same time as well, and if some extension or theme isn't
> compatible with the new version it'd get disabled.

Yeah, I understand that. To use standard packaging system on okfn servers, you 
would have to have a single virtual server for each instance of ckan, not that 
it wouldn't have it's andvantages. As for the versions incompatiblity, this 
can be adressed by specifying versions of dependences correctly (something 
which is already done with python packages, or should be). As for the different 
platforms you have a point there. Though I would say a distributor should be 
preparing packages and since you only are de facto distributor in case of okfn 
servers, you could take care just about that and let other distributions to do 
the packaging according their standards. Well but what sould I be saying about 
that... Anyways, keep up the good work. 
Disabling not working extensions... wouldn't that be better done on the ckan 
level rather than on the packaging level? Or I just may be missing something 
here too.

Ondřej Vadinský
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2809 bytes
Desc: not available
URL: <http://lists.okfn.org/pipermail/ckan-discuss/attachments/20120605/24177035/attachment.bin>