ANN: TurboGears 1.0.4.2 Released

[Christopher Arndt]

TurboGears 1.0.4.2 Released
===========================

The TurboGears team with its release manager, Florent Aide, is pleased
to announce the release of TurboGears 1.0.4.2.

This is the latest in a series of releases from the 1.0 branch, which
has been the stable version of TurboGears for more than a year now.
With this release the 1.0 branch will enter maintenance mode, which
means, that the TurboGears 1 Team will concentrate on preparing a beta
release of the 1.1 branch and only critical bug-fixes will still be
released for 1.0. (In the meanwhile, other folks from the TurboGears
team are putting together a preview release of the upcoming TurboGears 2
version -- but this is a different story.)

What is TurboGears?
-------------------

TurboGears is a popular rapid web development megaframework, built
from a number of great Python projects and with a bunch of high-level
features built within the TurboGears project. The goal of the project is
to ease development of modern web applications and support the full
stack from database back-end to the web client front-end.

For more information about the project and its goals please visit the
homepage:

http://www.turbogears.org/

Where to get it?
----------------

As always, TurboGears can be installed by following the instructions in
the wiki:

http://docs.turbogears.org/1.0/Install

What's New?
-----------

Since this is an important milestone in the TurboGears release history,
here's a summary of the most important changes from last couple of beta
versions leading up to this release. Detailed information can be found
in the ChangeLog as usual:

http://trac.turbogears.org/wiki/ChangeLog

Features:

* First stable release to support SQLalchemy 0.4.0.
* Many pagination improvements
* Many quickstart template improvements (logging, start-up scripts,
model, coding style)
* turbogears.url() has proper support for multiple parameter values and
parameters passed as lists.
* tg-admin quickstart allow to import a project into an SVN repository
when creating it.
- Many i18n improvements (string collection in Kid templates, JavaScript
i18n, tg-admin i18 command line interface)
- A lot of unit tests have been added.

Fixes:

- Important security fix (CVE-2008-0252) by now requiring CherryPy 2.3.0
- Fixes for visit cookie expiration and re-sending
- Many fixes in the parameter encoding/decoding logic
(Visit-/IdentityFilter)
- toolbox loading will no more crash trying to import missing SQLObject
module.
- Many i18n fixes (unicode handling, ignore XML PIs and comments)
- Several fixes in turbogears.testutil

Contributors
------------

Too many to name them all here ;-) Please see the ChangeLog at
http://trac.turbogears.org/wiki/ChangeLog for a list of contributors for
each release.

We would like to thank everybody involved for their support!

Christopher Arndt

[Ken Kuhlman]

On Jan 21, 2008 10:30 PM, Mark Ramm <mark.mch...@gmail.com> wrote:

> > the TurboGears 1 Team will concentrate on preparing a beta
> > release of the 1.1 branch and only critical bug-fixes will still be

> It's a good time to discuss about change the cherrypy version from 2 to
> 3.
> I know that the first try was done some time ago and developers have
> decided to stop migration, but, looking for cherrypy 3 features, maybe
> the benefits pay the work.

If people are willing to help, we're willing to try to make this
happen in 1.1.   I think the key things are 1) test infrastructure
updates and 2) updating the Turbogears configuraiton system to break
it out of cherrypy.

I think there are plans already to work on issue 2, and if somebody is
willing to integrate paste.fixture style testing into TG 1.1, that
will be a benifit as people move their apps from 1.1 to 2.0.

 
(Moving this conversation to the trunk list)

I've made a couple of attempts of working with the CP3 branch.  I'd like to share some of the lessons/mistakes I've made along the way..  hopefully someone will find value in them.

Starting with #2, the config system, it doesn't seem too difficult to hack together support for the new CP3 approach [1].   I posted something similar a while back, but Florent was working on a more complete re-write, so I didn't push the issue.  My hack seems to work, though, so maybe it's worth mentioning again.

Regarding #1, the test infrastructure, I've tried a couple of approaches.  First, I tried creating a "Fixture Like" class that wrapped cherrypy's response object to produce something that looked vaguely like paste.fixture.  At the time, it seemed like making this complete was more work than I had time for, so I then switched to twill, adding a feature to grab the wsgi environment when using wsgi_intercept (as a stand-in for testutil.call & call_with_request).  I had some success with this approach [2], but I ended up creating a big performance problem (~2 seconds per test) & somehow broke nose in the process.

I now view the attempt of moving to twill as too aggressive & a distraction -- there's enough already changing that we shouldn't add more needlessly.   So, I'm ready to switch back to doing something fixture-based, except for one question:  now that TG2 is using webob, does it follow that it will soon switch to using webtest?   If so, we should use/mimic that API instead.

The other question that comes up is how to get people to start doing something besides importing cherrpy & using it's response object in their tests.   It seems to me that create_request should return a webob-like response that should be used [3].    Should testutil monkey-patch cherrypy.response to issue a deprecation warning to let people know they should be switching over?


In the push towards tg 2.0, eventually something should also be done in the tests to abstract away mounting apps via assigning cherrpy.root, but that's another ball of wax.


Anyway, I hope some of this makes sense..  it's  late.
-ken


[1]  http://paste.turbogears.org/paste/1913
[2] I had about 1/2 the cp3 branch's unit tests running successfully, and just 12 failures against the 1.0 branch (and it works great for my own project.)
[3] testutil.call would return a tg specific portion of the wsgi env.  controllers.py would need to be modified to add stuff to the wsgi env.

[Mark Ramm]

> I now view the attempt of moving to twill as too aggressive & a distraction
> -- there's enough already changing that we shouldn't add more needlessly.
> So, I'm ready to switch back to doing something fixture-based, except for
> one question: now that TG2 is using webob, does it follow that it will soon
> switch to using webtest? If so, we should use/mimic that API instead.

AFIK webtest and paste.fixture have almost identical API's. But,
yea, we should be thinking webtest, not paste.fixture.

--Mark

[Mark Ramm]

> I've made a couple of attempts of working with the CP3 branch. I'd like to
> share some of the lessons/mistakes I've made along the way.. hopefully
> someone will find value in them.

This is all really good information. Thanks!

> Starting with #2, the config system, it doesn't seem too difficult to hack
> together support for the new CP3 approach [1]. I posted something similar
> a while back, but Florent was working on a more complete re-write, so I
> didn't push the issue. My hack seems to work, though, so maybe it's worth
> mentioning again.

Yea, Florent's always got some cool tricks up his sleeve. ;)

> Regarding #1, the test infrastructure, I've tried a couple of approaches.
> First, I tried creating a "Fixture Like" class that wrapped cherrypy's
> response object to produce something that looked vaguely like paste.fixture.

> The other question that comes up is how to get people to start doing
> something besides importing cherrpy & using it's response object in their
> tests. It seems to me that create_request should return a webob-like
> response that should be used [3]. Should testutil monkey-patch
> cherrypy.response to issue a deprecation warning to let people know they
> should be switching over?

well, the standard way of using webob or paste.fixture would be to
wrap the whole cherrypy app, and then the resulting wsgi response will
be turned into a response object by the test fixture. Couldn't we
change the way testutil works to just wrap the whole TG app in a
completely "framework agnostic" way for testing. If we do that we
can just give back a Response object (which is a WebOb response) that
has template_namespace as an attribute so that we can see what's in
the returned dictionary.

Testutil could be written to somewhat mimic the tg1.0 API by just
grabbing the template_namespace dictionary and returning it in the
proper cases. And we could issue deprication warnings and try to
encourage people to just use the agnostic fixture approach.

> In the push towards tg 2.0, eventually something should also be done in the
> tests to abstract away mounting apps via assigning cherrpy.root, but that's
> another ball of wax.

True enough, but that's not so much a testing issue ;)