uWSGI is extremely promising as an application server given its huge
range of options and supported platforms. For me, however, just getting
something seemingly simple up and running successfully was relatively
confusing. I’d like to contribute to the documentation when I can, but
thought a dedicated page about TileStache as a specific application
(and associated configuration) was warranted. It does make more sense
I want to serve my TileStache application at http://mydomain.com/tiles
(taking careful note of the sub-directory present). I’ve chosen an
INI-style configuration for my instance and here’s what the …
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.
Had this issue when you’ve been trying to run something like
Funnelweb, and you hit an ImportError for BeautifulSoup? You’re
definitely not alone, because I just hit the same issue. The answer is
simple — just ensure that you don’t use BeautifulSoup 4 or above (this
is still beta) — it uses a different namespace, specifically bs4.
Thus, whilst you might have the BeautifulSoup egg satisfying your
dependencies, any imports of this package are going to fail.
For me, I’m using buildout, so I just pinned my version of BeautifulSoup thusly:
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 …
This is pretty trivial (and trivial to fix), but I’m chronicling it for
my knowledge as much as anyone else’s. The issue is that a given Python
egg is missing some form of files, most commonly the ‘docs’ directory in
my experience, because the build wasn’t configured correctly.
The error goes somewhat like this:
Getting distribution for 'my.theme'.
error: docs/HISTORY.txt: No such file or directory
An error occured when trying to install my.theme 1.5.0. Look above this message for any errors that were output by easy_install.
Okay. So, anyone out here who’s listening — particularly those
overly-enthusiastic users — don’t try to recursively wget your
Plone site (or other CMS, for that matter) whilst you’re logged in with
an account that can make edits. It will lead to a very bad situation
where your site administrator and technical team need to step in and fix
your mistakes. For the uninitiated, a loose recursive wget (when logged
in with some degree of Edit rights) will hit every link that’s on your
pages, and I mean in the (X)HTMLsource. For a Plone site, this …
Having a bad day? Just bombed your only copies of some files that you’d
been storing as blobs together with your Plone database? Maybe you had
the blobs stored incorrectly on your Zeo client, rather than the server,
and then in a hasty effort to free some space (due to an on-going issue
with blobs eating HDD space), deleted them. Whoops..they’re gone and
their references are still in your Plone database. Or, in a less
disastrous situation, maybe you just want to be able to run your Plone
database without needing lost blobs? Read on.The suggestion …
Due to various reasons, the Products.LDAPUserFolder package available
for Plone and Zope doesn’t support POSIX groups. The ‘official’ (ish)
reason for this is because of the fact that these groups don’t store
full distinguished names (DNs) for members. It makes some degree of
sense, because a user ID like ‘david.test’ isn’t strictly unique. On
the other hand, these types of groups are quite common in LDAP
implementations; not supporting them without giving it at least half a
shot to find the user seems a bit strange.
These titles of my posts just keep getting longer and longer. For those
of you paying close attention (I know who you are), this is the next in
my series of getting the above-mentioned tools working together.
Previously, it was Centos 5.x, Jaunty (9.04), Karmic (9.10) and now
Lucid (10.04). Only subtly different, each of this distributions has
pretty much called for its own post on the matter of getting a working
Plone 3.x / Python 2.4 virtualenv installation going. So, here goes
this time around.
Whoops. No one sent me the memo that Python
2.4 support was being removed entirely from the latest version of
Ubuntu, 10.04 Lucid Lynx. To be fair, I was presented with the message
that ‘these outdated packages will be removed’ and in that list was
python2.4. I made the unfortunate assumption that this just mean the
package was outdated (which it certainly is) and I’d have the ability to
install it again in Lucid. There were a number of different packages on
the list and in order to save time, I let the updater remove them …