On Jan 20, 2006, at 10:20 AM, Jorge Godoy wrote:
Bob Ippolito <[EMAIL PROTECTED]> 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
