> Have you considered using paste.fixture for the functional tests?

I think paste.fixture, or scotch (from Titus Brown) are both good options
for functional tests.

I'm not familiar enough with either package (though I've used scotch) to
know the benifits of either one.

But I think we absolutely should look at past deploy more deeply since when
we got together with the other web frameworks guys, most of us including
Pylons, Zope, and many others  are looking at it as a bit of a standard, or
at least something that we can build a standard off of.

We all committed to looking at Paste Deploy more deeply this week, and
discussing this on the WEB SIG mailing list.

--Mark Ramm

That would decouple the tests from CP completely as it treats the
> whole cow as an opaque WSGI app which is ideal IMO. I did some
> experiments with paste.deploy and CP3 a while back which I have here
> [1] if you guys want to take a peek. The paste.app_factory entry
> point that builds the CP3/TG WSGI app is implemented here [2].
> Something similar can be done to create the app that needs to be fed
> to  fixture's TestApp. Just some thoughts....


Are you sure these are CherryPy 3 or are they CherryPy 2 based?

You guys are doing an amazing job out there at PyCON! (so great
> you're distracting me too much from this project that's keeping me
> away from the world) Keep it up! (and leave some coding to do for the
> poor souls who cannot join you now... =)


Oh, I think we'll  it to you to integrate some of this CherryPy/paste stuff.


I've not used paste before, so I'm starting to mount that learning curve,
but for now my plan is just to keep moving on raw CP3 integration (which
seems now to be cleaning up some code and making things nicer).

But I absolutely agree that we should be working our way into the
paste.deploy world incrementally.

This is an exciting time for TurboGears, and we'll see what we get.

Also, I'm excited to see what can happen when we start pulling out the rest
of the "internal" components and turning them into reusable libraries and
WSGI middleware.

Long term I think we should do a TurboGears 1.X branch where we try to
support current users on new versions of the same core, and a 2.X branch
where we do the explosion of new eggs, more paste integration, and work
towards creating the TurboGears of the future.

-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to