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
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?
You shouldn't have to, but that'd be your most expedient solution at the moment.
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?
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.
> 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>
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.
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
> 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
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
> 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