This one couldn’t be simpler, but it’s worth noting all the same. I’ve just
experienced a situation where a virtualenv was being completely ignored by
all tools even though it was absolutely activated via source bin/activate.
The answer was to blow away the lib directory within the virtualenv and
blow away the local Python interpreter at bin/python and re-create the
virtualenv. After deactivating and re-activating, everything works correctly again.
I guess something in the environment (or env variables) got messed up.
Who knows; it works now.
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:
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!).
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:
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.
Here’s an interesting error message I got stumped with for a good set of
hours. The issue started with me using collective.autoreload with Plone
and it does the trick, mostly. With any such ‘operation’ and live
reloading of code for Python, you’ve got to expect that not everything
will go according to plan. Most things do, but one issue I found
presented with this error message:
< ... huge traceback ...>
TypeError: super(type, obj): obj must be an instance or subtype of type
The issue arises for me (and you’ll probably see it elsewhere) when I go
It’s amazing to see how technologies can be so smoothly integrated these
days. I’m talking, at least in this instance, about how setuptools
works with PyPI (and then Plone.org’s Products section) and allows you
to distribute your product(s) to the world. So far, I’ve just got the
one — collective.portlet.googleapps — but I’m sure time will pass and
I’ll have some more useful things to contribute. Here’s a summary of
what I did:
Create the product. ZopeSkel is a wonderful help here for Plone
products. [I lie a little bit in …
Alright, now for today’s problem: why do two dates that look different
when outputted actually end up being the same date?
Answer: I’m not sure, but I’m pretty sure it’s got something to do
with the wacky support the above-mentioned 3 products have for timezones.
The background: Plone stores a DateTime object to record a user’s
last login time. It doesn’t really matter what’s purpose is, because
Plone (this time) isn’t at fault. The DateTime gets stored, no
worries. The problem arises when you try to put that value back into a …