Hi Max,

Welcome back to the trunk list :)

On Mar 27, 2007, at 8:19 AM, Max Ischenko wrote:

> Alberto,
>
> On 3/26/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
> I think we all agree on this. The port to CherryPy 3 is almost done
> in the cp3 branch, just needs the tests adapted as the current ones
> are too closely tied with CP2's internals (I'll give a shot at this
> in a few days) and widgets ported from 1.0 as the ones in trunk give
> the wrong impression if being 100% usable with Genshi which is not
> the case.
>
> Once this is done we can merge that branch with the trunk and release
> a 1.1 alpha. This reminds me of something important: Any patches that
> are merged from 1.0 to trunk should also go into the cp3 branch until
> it's merged. Hopefully this situation will end soon but please try to
> keep an eye on it now so we don't miss anything.
>
> If I am to work on CP3 branch, what's the procedure?

In danger of stating the obvious I'd say it all boils down to check  
it out from SVN and work from there. I'm probably missing the precise  
meaning of the question so please ask any specifics.

Mark has been the main force behind it (apologizes to all the other  
coders that worked on it at PyCON) so he'll probably be in a better  
position than me to provide details about the state of the branch.

>
> Are there any cp3-specific tickets? Do I need to do any merging  
> from 1.0?

No tickets that I'm aware of. In fact, the 1.1 milestone in Trac is  
currently a collection of all tickets that don't fit into 1.0.2 so  
don't pay much attention to them.

The main task needing work is migrating the tests to an independent  
testing framework to decouple them from CP2. I was thinking of  
paste.fixture for this but any framework that treats a TG app as an  
opaque WSGI app will be fine too. Once they all pass we can merge  
that branch into trunk and continue from there.

Before doing this, we need to implement a paste.app_factory  
entrypoint to build a WSGI app out of a TG/CP3 app so we can feed it  
to whatever fixture we use. I was thinking of implementing that as a  
bunch helper functions inside TG which handled common stuff (starting  
up TG's extensions, etc... those things implemented in turbogears/ 
startup.py) and then calling them from inside the entry point inside  
the users application package. I'm sure you'll be familiar with this  
because it's very similar to what Pylons does in middleware.py

There's also work needed in order to adapt our config to CP3's. A  
Paste Deploy .ini config is not needed for now but it should be easy  
to use one once we provide the needed entry point.

Eventually I think it'll be a good idea to reimplement start-myapp.py  
as a simple wrapper around paste's loadapp (to load the app provided  
by the entry point) and loadserver (to load CP3's wsgi server). This  
setup should make trivial to integrate a TG/CP3 app into a bigger app  
and vice versa (the Pylons folks will probably love us once they can  
use CatWalk and Co. in their apps ;), not to mention that we'll have  
all existent middleware easily available to use in a TG app)

I did some experiements a while back implementing this so you might  
want to take ideas from there. the paste entrypoint is declared here:

http://tinyurl.com/tjhb8

However, ignore "Tree" because it's not really needed (and I had to  
hack it to make it treat SCRIPT_NAME in a way paths defined in CP3s  
config worked properly) or encouraged as dispatch to multiple apps  
can be done using URLMap or directly in a paste.deploy config. This  
ticket at CP can also help:

http://cherrypy.org/ticket/638

and this document too:

http://tinyurl.com/2gf4xv

Take a look at the experiment at my repository because there's also  
some code integrating CP3's config that might help.

>
>
> > I think we should release 1.0.2 ASAP (at least give it a date) and
> > toward next step, ex: test CP3 branch and make some docs about  
> genshi/
> > sqlalchemy,
>
> There are a couple of pending tickets and patches which need to be
> commented on, applied or discarded. New features should not be
> committed IMO unless they are 99% risk free and obviously missing
> from what the API suggests should be possible (I know, this can be
> very  subjective.... that's what this ML is for... :)
>
> What are those tickets? Can I help?

Those at the 1.0.2 milestone. However, they're not strictly needed to  
get 1.1 out (although they'll need to be merged when done) so if you  
just want to help for 1.1 don't bother about them.

>
> P.S.: I am in process of starting another TurboGears project and I  
> want it to be on 1.0.2 with SA, Genshi and CP3, just like the rest  
> of us. ;) The client is willing to sponsor some of the work.

That's great!

Alberto


--~--~---------~--~----~------------~-------~--~----~
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