bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <ryan.ol...@wandisco.com>
Subject Re: UndefinedError: "_dgettext" not defined
Date Sat, 07 Sep 2013 16:02:12 GMT
On Sat, Aug 31, 2013 at 9:58 PM, Ben <bugreporter@vescent.com> wrote:

> I 'fixed' my problem with the login page returning
>
> UndefinedError: "_dgettext" not defined
>
> I installed Bloodhound 0.7 on a different debian 64bit Wheezy machine
> (well, rackspace cloud server) and it worked. So I copied all the files
> over to my server with the install problems (also rackspace 64bit Wheezy),
> and it worked fine. I don't know what the relevant difference between the
> two machines -- maybe some weird config on that server messed up the python
> virtualenv or something, (or maybe having parallel earlier version of trac
> installed and in the path causes some problem). But I can now play with
> Bloodhound, so I'm happy. If someone has an idea what the problem is/was
> and wants me to test potential fixes, etc, let me know.
>
> Ben
>

I think the issue was that you had a copy of AccountManager installed
outside of your virtualenv, and it was being used in Bloodhound's
virtualenv since we specify the --system-site-packages option when create
the virtualenv. The version of AccountManager was probably older than what
we currently use (0.4.3), and not did pass `_dgettext` to the template.

Loading acct_mgr.admin from /usr/lib/pymodules/python2.7

I've had a suspicion for a while now that --system-site-packages is causing
quite a few problems that users are reporting, and I think we need to
revisit the issue of whether we should try to find a way to avoid using
this option. It was originally added so that psycopg2 could be utilized
from the system packages. Here are some references to previous discussion:

http://apache.markmail.org/thread/v6kehi7zyvroseg3
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall?action=diff&version=20&old_version=19

I know it is possible to "pull in" packages by creating symbolic links in
the virutalenv, however it is probably not practical for us to provide
instructions with the proper paths for all platforms. Just as an example
though, I've found that the following works on Ubuntu Debian to make
python-subversion available to a virtualenv:

Add an svn.pth file in lib/python2.x/site-packages with the single line:
/usr/lib/pyshared/python2.x/libsvn

Add symbolic links in lib/python2.x/site-packages:
svn -> /usr/share/pyshared/svn
libsvn -> /usr/share/pyshared/libsvn

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message