Experimental Pylons-less branch

[Alessandro Molina]

I pushed an experimental branch of TG2 which doesn't depend on pylons
for most central things like dispatch and TGApp. Only caching and i18n
still depend on it.
This made also possible to support WebOb1.2, which is a good step in
the direction of supporting Python3.

All the test units pass and the apps I tried work correctly at first
sight, any review is well appreciated

You can take a look at
http://sourceforge.net/p/turbogears2/tg2/ci/448efd4368a7167f5a7f00ee3ef0bba96ac8e4ca/log/

[Alessandro Molina]

Last commit is now able to run the quickstart application in an
environment where Pylons is not installed at all.

Few issues have to be fixed and probably left around some parts that
are pylons related and now useless.
Also performances need to improve as things got a bit slower than the
pylons based version, but it is a really good starting point.

Also repoze.what-pylons package is not required anymore.

[Mengu]

what exactly has decreased the performance?

On Dec 10, 12:57 am, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:

> >http://sourceforge.net/p/turbogears2/tg2/ci/448efd4368a7167f5a7f00ee3...

[Alessandro Molina]

On Sat, Dec 10, 2011 at 1:13 AM, Mengu <whal...@gmail.com> wrote:
> what exactly has decreased the performance?
>

Nothing in particular, just rushing unoptimized code as fast as
possible to have things working.
I'll take a look at it in the next week removing the performance bottlenecks.

[Alessandro Molina]

Now pylons-less branch passes all the tests both with and without
pylons installed and is now a bit faster than the pylons based branch.

On Sat, Dec 10, 2011 at 1:31 AM, Alessandro Molina
<alessand...@gmail.com> wrote:
> On Sat, Dec 10, 2011 at 1:13 AM, Mengu <whal...@gmail.com> wrote:
>> what exactly has decreased the performance?
>>
>

[Christoph Zwerschke]

Am 12.12.2011 00:20, schrieb Alessandro Molina:
> Now pylons-less branch passes all the tests both with and without
> pylons installed and is now a bit faster than the pylons based branch.

Congratulations! This is really a big step forward.

Did you run some real-life TG apps with that branch? Unfortunately, our
test suite is not very comprehensive, so we should test this with some
of our apps and add more unit tests if we notice any problems. Hope I
can find some time over the holidays for giving this a try.

-- Christoph

[Alessandro Molina]

Not really, I have a fake app I use to develop that practically ended
up being a test suite as it uses every single tgext that I wrote and
they seem to work.
But it doesn't test for example session, i18n and configuration.
Yes, I still don't know if it cares about the config options, the
config object was quite pervert (wrapper of a wrapper of a
DispatchingConfig used as a StackedProxy) and I'm afraid that I might
have broke something.

I'll be really glad to anyone that has a few hours to invest testing
the pylons-less branch on any applications that he has available.
Just keep in mind that it is based on TG2.1.4 so the application
itself has to be compatible with TG2.1.4

Even pylons based controllers should work, just check that
tg.pylons_compatible is True.
Disabling it makes the app go faster at the price of not being
compatible with Pylons related Controllers (XMLRPCController for
example)

My current target for the branch is to achieve 100% code coverage on
the TG module.

[Mengu]

i'll give it a try on my local for osesturkiye.com. what are the steps
i should follow?

* i've created a virtualenv --no-site-packages

* git clone the pylonesless branch

* ran bin/python setup.py develop

* in my app i ran ../bin/paster setup.py develop and got an error for
tg.devtools so i went and downloaded and did a setup.py for it.

i've not noticed any performance increasements and it seems the
current branch seems faster but not that much. i did not have any
problems with my tg app. everything is working.

On Dec 12, 11:22 am, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:

[Alessandro Molina]

On Mon, Dec 12, 2011 at 1:44 PM, Mengu <whal...@gmail.com> wrote:
>
> i've not noticed any performance increasements and it seems the
> current branch seems faster but not that much. i did not have any
> problems with my tg app. everything is working.

By default tg.pylons_compatible is True, so it should actually be
slower then before.
Please, try to set ['tg.pylons_compatible'] = False inside your
app_cfg and let me know if you see any performance boost.

It might break the app anyway if you use any request local object from
pylons namespace.

[Mengu]

sorry, do you mean base_config['tg.pylons_compatible'] or something
else?

On Dec 12, 3:34 pm, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:

[Alessandro Molina]

On Mon, Dec 12, 2011 at 2:53 PM, Mengu <whal...@gmail.com> wrote:
> sorry, do you mean base_config['tg.pylons_compatible'] or something
> else?
>

Yes, that one. Set it to False.

[Mengu]

okay, done that. still not much difference and did not have any issues
on the app as i'm using the basics.

On Dec 12, 4:24 pm, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:

[Alessandro Molina]

Well that speeds up TG itself, but keep in mind that most of the
slowdown cames from the database and template engine.

So you would see an huge boost only if you test it against a
controller method that doesn't access the DB and doesn't render a
template :D

> --
> You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
> To post to this group, send email to turbogea...@googlegroups.com.
> To unsubscribe from this group, send email to turbogears-tru...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
>

[Mark Ramm]

Yes, I still don't know if it cares about the config options, the
config object was quite pervert (wrapper of a wrapper of a
DispatchingConfig used as a StackedProxy) and I'm afraid that I might
have broke something.

Well, to be honest the old config had a strange (and I though very problematic) problem in that it allowed dotted notation for lookup, and mostly but not always for setting config options.   

Anyway, I think the config object issues did not turn out to be nearly as difficult to maintain as the load order of the quickstarted middleware setup files.   But all that was inherited from Pylons, and we should think about making them cleaner in new quickstarts someday.     

I'll be really glad to anyone that has a few hours to invest testing
the pylons-less branch on any applications that he has available.
Just keep in mind that it is based on TG2.1.4 so the application
itself has to be compatible with TG2.1.4 

Even pylons based controllers should work, just check that
tg.pylons_compatible is True.
Disabling it makes the app go faster at the price of not being
compatible with Pylons related Controllers (XMLRPCController for
example)

We should probably do this the oposite way (since most existing apps will not have tg.pylons_compatible already, so they will break on upgrade to this branch if they use the controllers.  So for example we could set: 

 tg.no_pylons_controllers = True  

In quickstart, and tell people about it as an optimization when they upgrade, but not break their code. 

My current target for the branch is to achieve 100% code coverage on
the TG module.

That's great!

[Alessandro Molina]

On Sat, Dec 24, 2011 at 3:19 AM, Mark Ramm <mark...@gmail.com> wrote:
> We should probably do this the oposite way (since most existing apps will
> not have tg.pylons_compatible already, so they will break on upgrade to this
> branch if they use the controllers.  So for example we could set:
>
>  tg.no_pylons_controllers = True
>
> In quickstart, and tell people about it as an optimization when they
> upgrade, but not break their code.
>

Hi Mark,
It should already work that way as the pylons_compatible option
defaults to True, so if you don't have it "False" inside your app_cfg
you will get the system with pylons compatibility enabled. My idea was
to quickstart future applications with that option set to True inside
the app_cfg and let the old apps continue to work as they used to do.