note to those following svn: nose now required
Kevin Dangoor
requirements list. Luckily, you can get yourself set up with nose with
"easy_install nose"
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Tim Lesher
>
> Based on the discussion about testing, I've added nose back to the
> requirements list. Luckily, you can get yourself set up with nose with
> "easy_install nose"
OT, I know, but the commit message was probably the funniest I've seen in TG:
"[turbogears-commits] [544] trunk: requires nose"
Perhaps I need to "easy_install elephant"?
--
Tim Lesher <tle...@gmail.com>
Mike Kent
But there are failures. Apparently sqlite is also required now?
Jorge Godoy
Only people who have "easy_install mouth" can pronunciate... :-) Ops, I
should be quiet... :-)
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
>
> Excellent, 'nosetests' in the svn checkout directory now works.
>
> But there are failures. Apparently sqlite is also required now?
Yeah, I should mention that somewhere. sqlite is *not* required by
TurboGears itself, but the tests do require it. sqlite is a very good
database for tests because you can make an in-memory database which is
blazingly fast and requires no cleanup.
Kevin
Bob Ippolito
Maybe the tg-admin quickstart template should include a sqlite db uri
relative to the project, so you can get right into the toolbox and
get prototyping after a quickstart? Would also be nice to have a
tool to migrate one DB URI to another, given a model module.
-bob
Soni Bergraj
> relative to the project, so you can get right into the toolbox and get
> prototyping after a quickstart? Would also be nice to have a tool to
> migrate one DB URI to another, given a model module.
--
Soni Bergraj
Jorge Godoy
Me too. But even then, I don't expect sqlite to be a requisite for TG.
--
Jorge Godoy <jgo...@gmail.com>
Bob Ippolito
Why not? SQLite is something most people should have anyway; it's
the best tool for many tasks -- especially tests, as Kevin said.
It's not heavy either, less than 250k as an egg.
-bob
Jorge Godoy
> Why not? SQLite is something most people should have anyway; it's the best
Because there are a lot of projects that don't need it. And TG works fine
without it, just testing fails -- and we don't run tests on production
environments.
> tool for many tasks -- especially tests, as Kevin said. It's not heavy
> either, less than 250k as an egg.
I'm not worried with space here... It just isn't needed for normal
operation. Otherwise we'd start requiring MySQL, PostgreSQL, etc. that are
also supported (I know it is *very* different, but why add a dependency that
doesn't exist?)...
Just because it is small I don't think it should be there. And since it is
small enough and easy enough to install, one line at the docs would solve the
problem:
"To run tests you'll need to run: easy_install sqlite"
I am still thinking about this new 'nose' requirement... It is nice for
development environments, but why have it on a production server? It was
optional before and is needed now...
I like having the tools, but if it is easy to install them, and it is in the
docs, and they aren't required for normal operation, why requiring them all
the time, even on a production environment?
--
Jorge Godoy <jgo...@gmail.com>
Bob Ippolito
On Jan 20, 2006, at 10:20 AM, Jorge Godoy wrote:
>
> Bob Ippolito <b...@redivi.com> writes:
>
>> Why not? SQLite is something most people should have anyway;
>> it's the best
>
> Because there are a lot of projects that don't need it. And TG
> works fine
> without it, just testing fails -- and we don't run tests on production
> environments.
You also don't want your production environments to be very different
from your development environments.
>> tool for many tasks -- especially tests, as Kevin said. It's not
>> heavy
>> either, less than 250k as an egg.
>
> I'm not worried with space here... It just isn't needed for normal
> operation. Otherwise we'd start requiring MySQL, PostgreSQL, etc.
> that are
> also supported (I know it is *very* different, but why add a
> dependency that
> doesn't exist?)...
Why care? If you weren't paying attention to the list or svn, you
probably wouldn't even have noticed.
> Just because it is small I don't think it should be there. And
> since it is
> small enough and easy enough to install, one line at the docs would
> solve the
> problem:
>
> "To run tests you'll need to run: easy_install sqlite"
>
> I am still thinking about this new 'nose' requirement... It is
> nice for
> development environments, but why have it on a production server?
> It was
> optional before and is needed now...
It's absolutely useful to have the capability to test on a production
server, especially right before you deploy.
So you propose that instead of adding a little code, we require users
to read more documentation? That's backwards. The idea is to make
things easier, and having something get installed for you is a hell
of a lot easier than reading docs.
I don't think that avoiding a couple unused files in a directory that
you never look at on a production server is a very good justification
for anything, especially not if it's in exchange for ease of use.
> I like having the tools, but if it is easy to install them, and it
> is in the
> docs, and they aren't required for normal operation, why requiring
> them all
> the time, even on a production environment?
It's easier to require it than to document it and make people read
the docs. People don't read documentation unless something goes wrong.
TurboGears is great because it's easy to get up and going, the only
thing you need to remember how to do is run tg-admin and adjust your
db uri. To that end, I've proposed that the quickstart db uri should
default to an in-project-dir SQLite database to remove that
requirement for prototyping. It also makes the barrier to entry a
lot lower for someone who just wants to download TurboGears and go
through some of the tutorials.
There's a shitload of things in Python and TurboGears that you don't
use in a production environment, but it doesn't mean the space they
take up on disk does any harm. They aren't additional security
risks, they don't get in the way, and they don't make TurboGears
harder to install or deploy. I really don't see any justified reason
to avoid their inclusion.
-bob
Jorge Godoy
> You also don't want your production environments to be very different from
> your development environments.
Exactly! I also don't want to worry with things I don't need on my production
environment. The cleaner the better.
> Why care? If you weren't paying attention to the list or svn, you probably
> wouldn't even have noticed.
I pay attention to both...
> It's absolutely useful to have the capability to test on a production server,
> especially right before you deploy.
If I'm testing what I'm deploying, I'll test the whole chain. If sqlite is in
it, then I'll use it. If it is not, why would I care what happens with it?
> So you propose that instead of adding a little code, we require users to read
> more documentation? That's backwards. The idea is to make things easier,
> and having something get installed for you is a hell of a lot easier than
> reading docs.
I find it easy to read documentation. If it is installed and not documented,
it is probable that it won't be noticed...
> I don't think that avoiding a couple unused files in a directory that you
> never look at on a production server is a very good justification for
> anything, especially not if it's in exchange for ease of use.
What ease of use? More things to install, to maintain, etc. If you use
sqlite, then it is a plus, if you don't, why having it there?
> It's easier to require it than to document it and make people read the docs.
> People don't read documentation unless something goes wrong.
And people don't use the tools unless they know it is there... How to tell
them it is there?
> TurboGears is great because it's easy to get up and going, the only thing you
> need to remember how to do is run tg-admin and adjust your db uri. To that
> end, I've proposed that the quickstart db uri should default to an
> in-project-dir SQLite database to remove that requirement for prototyping.
> It also makes the barrier to entry a lot lower for someone who just wants to
> download TurboGears and go through some of the tutorials.
I agree that it makes it easy, but making this a requirement for those that
already know turbogears and are using it for real projects is a bit
different.
> There's a shitload of things in Python and TurboGears that you don't use in a
> production environment, but it doesn't mean the space they take up on disk
> does any harm. They aren't additional security risks, they don't get in the
I'm not concerned with space. And two wrongs doesn't make one right. I don't
believe that just because there's a lot that isn't used more should be added.
If it is, I'll live with that, but I don't see why adding it.
> way, and they don't make TurboGears harder to install or deploy. I really
> don't see any justified reason to avoid their inclusion.
We think in opposite directions. It will an infrutiferous discussion in the
end, since none of us will make the other change his mind. If there were good
reasons, it could lead somewhere, but arguing that just because there are more
things there and because it is small enough is not what I believe to be the
right thing to do...
My vote is -1 for adding this. Your is +1. If there are more "+" than "-",
then I'll have to live with that. If there are more "-" than "+" then you'll
have to live with that...
In the end, it's up to Kevin :-) We just comment and he decides...
--
Jorge Godoy <jgo...@gmail.com>
Ronald Jaramillo
________________________________
Ronald Jaramillo
mail: ronald AT checkandshare DOT com
blog: http://www.checkandshare.com/blog
Mike Kent
latest sqlite, compile and install it, no problem. Then of course, I
need pysqlite, so I easy_install it, no problem. Then I try to run
'nosetests'. Problem. SQLObject is trying to import 'pysqlite2',
which is not found. Odd, because the version of pysqlite I installed
is 2.1.1. Any ideas?
Michele Cella
Setting the db uri (and at this point I would add executing tg-admin
sql create) usually to your project dir is the step I hate.
To address Jorge concerns, I would propose to not make SQLite a
dependency (no problem for me anyway).
Maybe we can try to import pysqlite and if we don't get an exception we
can ask something like:
"Do you want turbogears to prepare a SQLite database for your project?
[Yes]"
Yes, give me a db ready to go.
Ciao
Michele
Bob Ippolito
On Jan 20, 2006, at 5:27 PM, Michele Cella wrote:
> Setting the db uri (and at this point I would add executing tg-admin
> sql create) usually to your project dir is the step I hate.
>
> To address Jorge concerns, I would propose to not make SQLite a
> dependency (no problem for me anyway).
>
> Maybe we can try to import pysqlite and if we don't get an
> exception we
> can ask something like:
> "Do you want turbogears to prepare a SQLite database for your project?
> [Yes]"
>
> Yes, give me a db ready to go.
Running tg-admin sql create doesn't do anything unless there's
something in your model. Adding a tg-admin sql create button and/or
checkbox next to "Write model" would be a nice addition to
ModelDesigner though.
There's no need to ask the question -- it should just put a SQLite DB
URI in there (if pysqlite is installed). It won't create the DB
until it needs to, and creating a SQLite DB is better than an error.
If you have a need to manually specify a DB URI, you'd simply just
comment out or change that line.
-bob
Michele Cella
>
> Running tg-admin sql create doesn't do anything unless there's
> something in your model. Adding a tg-admin sql create button and/or
> checkbox next to "Write model" would be a nice addition to
> ModelDesigner though.
>
You are right indeed, we can't imagine (yet :D) what DB structure the
user will need.
> There's no need to ask the question -- it should just put a SQLite DB
> URI in there (if pysqlite is installed). It won't create the DB
> until it needs to, and creating a SQLite DB is better than an error.
> If you have a need to manually specify a DB URI, you'd simply just
> comment out or change that line.
>
Yes, that would be really useful and not in the way if you don't need
it.
Ciao
Michele
Mike Kent
longer works. Running it gets:
[mike@pengy turbogears]$ nosetests
E
======================================================================
ERROR: test module turbogears in
/home/mike/Work/projects/turbogears/turbogears
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/usr/local/lib/python2.4/site-packages/nose-0.8.4-py2.4.egg/nose/core.py",
line 409, in run
self.setUp()
## LOTS OF LINES ELIDED ##
File
"/usr/local/lib/python2.4/site-packages/kid-0.8-py2.4.egg/kid/pull.py",
line 407, in feed
raise e
ExpatError: mismatched tag: line 22, column 2
----------------------------------------------------------------------
Ran 0 tests in 0.629s
FAILED (errors=1)
Daniel Holth
Any plans for the all-Python in memory SQL database gadfly? It doesn't
even need machine-specific object code.
I am happy using quantact.com for turbogears-compatible hosting, since I
don't mind managing an entire system and having root. They started out
as a user mode linux virtual hosting system and have transitioned nicely
to a Xen system and they have some decent tools. My virtual server runs
debian and even uses logical volume management.
- Daniel Holth
David Bernard
(Thanks for the info, I didn't know this RDBMS)
Daniel Holth a écrit :
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer
mailto:dwa...@java-fan.com
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
Daniel Holth
> is Gadfly usable with sqlobject ?
>
> (Thanks for the info, I didn't know this RDBMS)
Well, it's not usable with sqlobject right now. Does sqlobject require
any of these features?
"
* Nulls.
* Outer joins.
* CHECK conditions.
* Enforced data type constraints.
* Alter table (can't implement until NULLs arrive).
* Date, Time, and Interval data types
"
that are not implemented in gadfly? But check it out anyway. It is
really fun to have an all Python SQL database.
http://gadfly.sourceforge.net/
- Daniel Holth
Kevin Dangoor
> Well, it's not usable with sqlobject right now. Does sqlobject require
> any of these features?
>
> "
> * Nulls.
>
> * Outer joins.
>
> * CHECK conditions.
>
> * Enforced data type constraints.
>
> * Alter table (can't implement until NULLs arrive).
>
> * Date, Time, and Interval data types
>
> "
>
> that are not implemented in gadfly? But check it out anyway. It is
> really fun to have an all Python SQL database.
"Require" is a bit strong. Someone *could* probably implement an
SQLObject driver for Gadfly, but the lack of these features would
diminish the value greatly for testing, since these things commonly
come up in real databases. sqlite supports a large enough subset of
SQL (and even transactions!) so that it can reasonably be used for
testing real-worldish things.
Kevin
Kevin Dangoor
Sorry to be catching this more than a week later. Do you still have
this problem? nosetests runs fine for me.
Kevin
Michele Cella
Ciao
Michele
======================================================================
ERROR: test module tests.test_i18n in
/home/michele/Progetti/TurboGears/svn/turb ogears
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/core.py
", line 404, in run
self.setUp()
File
"/usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/core.py
", line 583, in setUp
self.module = self.loader._import(self.module_name, self.path)
File
"/usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/core.py
", line 261, in _import
return nose.importer._import(name, [path])
File
"/usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/importe
r.py", line 64, in _import
mod = load_module(fqname, fh, filename, desc)
File
"/home/michele/Progetti/TurboGears/svn/turbogears/tests/test_i18n.py",
li ne 31, in ?
sogettext.create_so_catalog(["en","fi"], "messages")
File
"/home/michele/Progetti/TurboGears/svn/turbogears/i18n/sogettext/__init__
.py", line 58, in create_so_catalog
TG_Message.dropTable(ifExists=True)
File
"/usr/local/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.eg
g/sqlobject/main.py", line 1308, in dropTable
conn = connection or cls._connection
File
"/usr/local/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.eg
g/sqlobject/dbconnection.py", line 856, in __get__
return self.getConnection()
File "/home/michele/Progetti/TurboGears/svn/turbogears/database.py",
line 42, in getConnection
raise AttributeError(
AttributeError: No connection has been defined for this thread or
process
----------------------------------------------------------------------
Ran 73 tests in 3.127s
FAILED (errors=1)
Unhandled exception in thread started by
Error in sys.excepthook:
Kevin Dangoor wrote:
> Hi Mike,
>
> [snip]
mbru...@cs.hmc.edu
> ERROR: test module tests.test_i18n in
> /home/michele/Progetti/TurboGears/svn/turb ogears
> ----------------------------------------------------------------------
> process
This seems to happen if "nosetests" imports the i18n.sogettext.model
module *before* importing and running tests.test_i18n. The solution I
found is to run "nosetests" inside the "turbogears/tests" directory.
Michele Cella
michele@ionic:~/Progetti/TurboGears/svn/turbogears/$ cd tests
michele@ionic:~/Progetti/TurboGears/svn/turbogears/tests$ nosetests
...
----------------------------------------------------------------------
Ran 69 tests in 2.691s
FAILED (failures=4)
michele@ionic:~/Progetti/TurboGears/svn/turbogears/tests$
Why 4 failures here and 1 from the project root? :-/
Ciao
Michele
Kevin Dangoor
> FAILED (failures=4)
> michele@ionic:~/Progetti/TurboGears/svn/turbogears/tests$
>
> Why 4 failures here and 1 from the project root? :-/
I get 4 failures when running in that directory as well. But I don't
get any failures at the project root.
Kevin