no operational unit testing framework in TG 0.9a1?

2 views
Skip to first unread message

Roger Rohrbach

unread,
Mar 16, 2006, 6:43:17 PM3/16/06
to TurboGears
According to the changelog
(http://www.turbogears.org/preview/about/changelog.html), TG 0.9a1 uses
nose for testing.

When I run nose from my project root, I get:

ImportError: No module named sqlite

This dependency seems to be introduced by the TurboGears testing
framework (nose certainly doesn't need SQLite). Yet SQLite is not
bunded with TurboGears. This seems odd. Am I missing something?

thx,

Roger

Karl Guertin

unread,
Mar 16, 2006, 6:54:41 PM3/16/06
to turbo...@googlegroups.com
On 3/16/06, Roger Rohrbach <ro...@ecstatic.com> wrote:
> This dependency seems to be introduced by the TurboGears testing
> framework (nose certainly doesn't need SQLite). Yet SQLite is not
> bunded with TurboGears. This seems odd. Am I missing something?

Not a solution, just a response. sqlite IS needed for running
nosetests on the turbogears trunk, so it's unsurprising that the
developers wouldn't catch this. To get the obvious out of the way: Are
you attempting to use sqlite in your project? not in the dburi and
whatnot?

Roger Rohrbach

unread,
Mar 16, 2006, 7:09:59 PM3/16/06
to TurboGears
I'm not using SQLite. I guess my question was: do I have to and
install it? And I guess the answer is...yes. :-) Thanks.

Karl Guertin

unread,
Mar 16, 2006, 7:14:35 PM3/16/06
to turbo...@googlegroups.com
On 3/16/06, Roger Rohrbach <ro...@ecstatic.com> wrote:
> I'm not using SQLite. I guess my question was: do I have to and
> install it? And I guess the answer is...yes. :-) Thanks.

You shouldn't have to, but that'd be your most expedient solution at the moment.

Sean De La Torre

unread,
Mar 16, 2006, 7:29:29 PM3/16/06
to turbo...@googlegroups.com
Although you theoretically shouldn't have to install it, the turbogears.testutil module automatically sets the database to a sqlite in-memory DB (turbogears.testutil, line 16).  So, though it is not obvious, sqlite is required if you want to use notetests, even if you don't use it elsewhere. 

The only reason I know about this is because I often modify that testutil setting to point to an actual test database for certain testing scenarios in my projects.

Sean

Roger Rohrbach

unread,
Mar 16, 2006, 8:17:27 PM3/16/06
to TurboGears
Hm. I installed SQLite 3.1.2 from a Fedora Core 4 source RPM, and
installed pysqlite 2.1.3. I still get "No module named sqlite"; it
seems like TurboGears doesn't know I've got the module.

I wonder if any of the TurboGears developers who can actually run
nosetests could tell me which versions of SQLite and pysqlite they're
running?

Karl Guertin

unread,
Mar 16, 2006, 8:30:03 PM3/16/06
to turbo...@googlegroups.com
On 3/16/06, Roger Rohrbach <ro...@ecstatic.com> wrote:
> Hm. I installed SQLite 3.1.2 from a Fedora Core 4 source RPM, and
> installed pysqlite 2.1.3. I still get "No module named sqlite"; it
> seems like TurboGears doesn't know I've got the module.

Looks like SQLite 2.8.16 and pysqlite 1.0.1 on the two machines I have
at hand. I'm pretty sure others are running newer code, though.

Jorge Godoy

unread,
Mar 16, 2006, 8:54:40 PM3/16/06
to turbo...@googlegroups.com
"Sean De La Torre" <sdela...@gmail.com> writes:

> Although you theoretically shouldn't have to install it, the
> turbogears.testutil module automatically sets the database to a sqlite
> in-memory DB
> (turbogears.testutil, line 16).  So, though it is not obvious, sqlite is
> required if you want to use notetests, even if you don't use it elsewhere. 
> The only reason I know about this is because I often modify that testutil
> setting to point to an actual test database for certain testing scenarios in
> my projects.
> Sean

Hmmm... I believe the correct would be having a testcfg.py with test
configuration. This could default to a sqlite database, but if changed, then
tests should use what was configured there.

Wanna try sending a patch for that and avoiding having to patch the source
code all the time? ;-)

--
Jorge Godoy <jgo...@gmail.com>

Roger Rohrbach

unread,
Mar 16, 2006, 9:39:34 PM3/16/06
to TurboGears
I redid my installs, w/ SQLite 2.8.15 (since that's what apt-get gives
me) and pysqlite 1.0.1. Now TG sez:

ValueError: You must use sqlite2 to use in-memory databases

This comes from sqliteconnection.py in SQLObject 0.7, which does:

try:
from pysqlite2 import dbapi2 as sqlite
using_sqlite2 = True
except ImportError:
import sqlite
using_sqlite2 = False
...
if not using_sqlite2:
raise ValueError("You must use sqlite2 to use in-memory
databases")

Now, I do have SQLite 2, but pysqlite 1.0.1 installs itself as
"sqlite," not "pysqlite2". And when I import sqlite, I can run an
in-memory database. In other words, the test in sqliteconnection.py is
spurious. I'm guessing this is legacy code dating from a time when
one could distinguish SQLite 2 support by the name of the installed
adapter.

When I change 'False' to 'True' in sqliteconnection.py, though,
nosetests still fails. This time, it's with:

opts["detect_types"] = sqlite.PARSE_DECLTYPES
AttributeError: 'module' object has no attribute 'PARSE_DECLTYPES'

PARSE_DECLTYPES was added to pysqlite in 2.0.7. Given that, and the
problem I see when trying to use 1.0.1, I can't understand how you are
able to run nosetests. Clearly, TG 0.9 expects at least
pysqlite-2.0.7. Maybe I'll get lucky if I install that.

Meanwhile, I think it's not overstating the case to say that unit
testing support in 0.9 is broken. It would only work if you happen to
have the versions of SQLite and pysqlite that SQLObject expects...and
if you're working in an environment where you're constrained to using
the RPMs from a particular Linux distribution, that is unlikely.

Kevin Dangoor

unread,
Mar 16, 2006, 9:52:32 PM3/16/06
to turbo...@googlegroups.com
Hi Roger,

I agree with you that either

1) sqlite should not be required to run nose on your own projects
2) sqlite should be required, but eggs should be available and there
should be install instructions for it

Requiring sqlite to run the tests on the trunk is one thing, but it's
something else entirely for TG projects. This issue did actually come
up before, and we talked about just recommending use of sqlite. But,
I'd prefer to see that configurable.

By the way, in reference to the below:

On 3/16/06, Roger Rohrbach <ro...@ecstatic.com> wrote:
>

> Hm. I installed SQLite 3.1.2 from a Fedora Core 4 source RPM, and
> installed pysqlite 2.1.3. I still get "No module named sqlite"; it
> seems like TurboGears doesn't know I've got the module.

I think your problem can be identified here:
http://initd.org/pub/software/pysqlite/doc/install-source.html

pysqlite 2.1.x requires SQLite 3.2.2+.

I think you'll find that pysqlite 2.0.x will work for you with that
version of sqlite. (This is one reason that I'm ultimately inclined to
get some statically linked eggs of pysqlite with sqlite together.)

Kevin

Liza

unread,
Mar 17, 2006, 10:17:16 AM3/17/06
to turbo...@googlegroups.com
On 3/16/06, Roger Rohrbach <ro...@ecstatic.com> wrote:

> Meanwhile, I think it's not overstating the case to say that unit
> testing support in 0.9 is broken. It would only work if you happen to
> have the versions of SQLite and pysqlite that SQLObject expects...and
> if you're working in an environment where you're constrained to using
> the RPMs from a particular Linux distribution, that is unlikely.

For what it's worth, I'd love to see this resolved. The major thing
holding me up in upgrading to the latest trunk is that I also couldn't
get SQLite and pysqlite working (RH Enterprise), so none of my 40+
tests run. Without my tests I can't determine what in my code needs to
change post-upgrade.

--Liza

Kevin Dangoor

unread,
Mar 17, 2006, 11:01:06 AM3/17/06
to turbo...@googlegroups.com
On 3/17/06, Liza <liza...@gmail.com> wrote:
> For what it's worth, I'd love to see this resolved. The major thing
> holding me up in upgrading to the latest trunk is that I also couldn't
> get SQLite and pysqlite working (RH Enterprise), so none of my 40+
> tests run. Without my tests I can't determine what in my code needs to
> change post-upgrade.

I've opened a ticket (for 0.9a2) to not require sqlite just for
testing TG user projects. (Testing TurboGears itself will still
require sqlite, and I do still hope we can get some nice statically
linked eggs together to clear all of this up.)

Kevin

Arthur Clune

unread,
Mar 17, 2006, 11:14:23 AM3/17/06
to turbo...@googlegroups.com

On 17 Mar 2006, at 16:01, Kevin Dangoor wrote:

> I've opened a ticket (for 0.9a2) to not require sqlite just for
> testing TG user projects

While we are talking about that, what's the status of the

AttributeError: 'thread._local' object has no attribute 'response'

errors when testing controllers.py? I'm trying to write some tests
that include database connectivity and it's not working at all at
the moment.

Also, someone else suggested testcfg.py for testing - that would work
really well for me.

Arthur

--
Arthur Clune. art...@clune.org
"[Film] only exerts its influence when it stirs patriots up against
other nations, or taps into agressive, violent urges" - Hayao Miyazaki

Roger Rohrbach

unread,
Mar 17, 2006, 1:38:44 PM3/17/06
to TurboGears
Thanks, Kevin. This sounds perfect.

Roger Rohrbach

unread,
Mar 17, 2006, 2:22:18 PM3/17/06
to TurboGears
Liza (and anyone else who's encountered this): If you can get the RPM
for sqlite-3.1.2-3, pysqlite 2.0.7 will compile against it, TurboGears
will be satisfied, and nosetests will work. :-)

Reply all
Reply to author
Forward
0 new messages