If you’re working with Buildout, then check out mr.scripty, a
fantastic Buildout recipe that allows you to use Python code in
functions within its options. This means that - in the few instances
I’ve used it so far - have conditional statements regarding effectively anything.
In the two examples I added to the source documentation, I go and
configure download links based upon architecture and separately,
configure some (Java) environment variables based upon which directories
exist (eg to handle different Linux distributions that might be
running). This is only the start, but it’s a fantastic one.
Today, I needed to migrate some legacy Plone installs set up using
Buildout. If I were to simply move the buildout files and re-run
buildout, I’d end up with the latest versions of add-on products - and
since I’m using legacy versions of Plone 3, that’d almost certainly
break the system. I do know about the Buildout extension
buildout.dumppickedversions (which does what its name suggests and
exports picked versions of eggs) but I can’t re-run buildout to get this
extension for risk of updating existing products (what I’m trying to avoid!).
After upgrading from Ubuntu 10.10 (Maverick Meerkat) to Ubuntu 11.04
(Natty Narwhal), you’ll probably find that if you’re running a Plone 4
buildout where you need to upgrade the Plone version, that compilation
of Zope will fail. The output will look something like this:
Getting distribution for 'Zope2==2.12.17'.
In file included from src/AccessControl/cAccessControl.c:51:0:
include/ExtensionClass/ExtensionClass.h:83:20: fatal error: Python.h: No such file or directory
error: Setup script exited with error: command 'gcc' failed with exit status 1
An error occured when trying …
What you may notice if you’re developing with Plone/Zope, is that if
you’re storing small pieces of data within Plone’s session variable (the
session_data_manager tool), data expires after a few minutes. By
default, this timeout is 20 minutes, but is far too short if you’re
expecting the information stored to last for say the whole time a user
is logged in. In this situation, you’ll need to increase the timeout.
Documentation on changing the session timeout is potentially a little
sketchy (Google “session-timeout-minutes zope”), but it’s clear that you
need to change the …
Yet another word to the wise: take care of your ordering of the
‘extends’ configuration files within your buildout. It makes complete
sense, and especially so with respect to version pinning: the later
configuration’s versions will be the last one applied.
So, it makes a lot of sense (in hindsight!) that this configuration, and
the fact I have version pins in my base.cfg, isn’t going to end well:
Writing unit tests (especial doctests) for your Plone product is
reasonably time consuming. For us developers, having tested code is
absolutely essential. This is especially true when clients are beating
down your door looking for a fully functional product and you need to
know what you’ve written works and isn’t going to fall over (just yet,
anyway). Web apps are able to be tested using a multitude of frameworks,
Zope’s doctest machinery is right there within your Plone product. In
order to write these, enter zope …
Plone 4 is approaching! Excellent! Lots of new features to play around
with and plenty more things to have to fix with the upgrade. I’ve been
keeping tabs on the change log of updates and it’s looking really good.
Lots of little, but significant, changes are afoot. Now, how about
actually installing the Alpha 2 version of Plone 4 to see it for real?
Let’s do it!
My steps are not going to work on your computer. I don’t think you’ll
be able to follow my words/commands exactly, but here goes anyway about
..and how true that is. Today’s time consumer is directly related to
just 1 misplaced line of a buildout configuration (and presumably
something that’s changed somewhere else).
After much hunting and hunting, it turns out my Zope2 Fake Eggs weren’t
On my long quest I had to go through downloading new packages and trying
to find something that had changed and even trying to establish new
virtual environments on different VMs. Nothing would fix the problem.
To rub salt in the wound, my desktop Ubuntu ran the buildout fine, so
methinks the underlying …
Taking a little bit of a time-out, I just have to ask the question: is
Buildout not the best thing ever? (and the people who are so very kind
to make the recipes?)
It’s made my work of managing our Plone infrastructure about 1000 times
simpler since moving from Instancemanager (ughhh) and having to manually
manage everything. I remember being a bit sceptical and very confused
the first time I saw a buildout configuration file and thought that I’d
never understand the thing.
Far, far from it of course! Whilst a little daunting at first, buildout
has (in …
install() got an unexpected keyword argument 'allow_hosts'
after trying to build zope2zeoserver from my buildout configuration.
After some searching, I found that it was due to my bootstrap.py script
(the one the gets buildout in the first place and creates the relevant
scripts) was actually pulling down an outdated version of zc.buildout.
So, the problem results because this old version of buildout doesn’t
have a clue how to handle the given argument.
Solution: update the buildout. For me, that meant correcting the
bootstrap script, but for you, it could be a matter …